ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Feature Flag (controlled EDI rollout)

The pattern that decouples deployment of a new version (mapping, validator, partner) from its visibility in production — the essential lever of safe and reversible EDI rollout.

Problem

Deploying a new version of a Walmart 850 mapping historically implies a full cycle: code review, deployment, pre-prod test, prod smoke test, 24-48h monitoring. If v2.0 produces a regression on 0.5% of messages (poorly-covered edge case), an urgent redeployment is required to revert to v1.0. Mean detect-and-rollback time is several hours, during which incorrect invoices are emitted. For an EDI hub with dozens of partners, each rollout is a risk bet.

Forces

  • v2.0 code and v1.0 old behaviour must coexist in production during the switchover period.
  • Control must be granular: per tenant, per partner, per message type, per traffic percentage.
  • Activation must be reversible without redeployment, in seconds.
  • Flags must be auditable: who modified them, when, for what reason.
  • Flags have a complexity cost: each flag is an if in the code, to be cleaned up once the switch is consolidated.

Solution

Wrap each new behaviour behind a named flag, queryable at runtime: features.mapping_v2_walmart_850, features.new_validator_en16931_2025. The code loads the flag from a centralised service (LaunchDarkly, Flagsmith, Unleash, or in-house implementation) and adopts v1 or v2 behaviour based on the value. The flag value can depend on context (tenant, partner, message type, % of traffic, hash of messageId for deterministic distribution). Activation is driven from a central console, audited, with instant rollback. 

Deployment vs activation decoupled:

   Deployment (live)         Activation (configuration)
   ───────────────────        ───────────────────────────
                              ┌─────────────────────────┐
   v2.0 of Walmart 850        │ feature_flag.partner=X  │
   mapping shipped to         │ enabled: false          │
   production                 │ override:               │
   (code packaged)            │   tenant_a: 10%         │
                              │   tenant_b: 100%        │
                              │   tenant_c: 0%          │
                              └─────────────────────────┘
                                          ▼
   Mapping router consults the flag:
   - tenant_a: 10% of messages → v2.0, 90% → v1.0
   - tenant_b: all → v2.0
   - tenant_c: all → v1.0 (old behaviour)

   If v2.0 produces anomalies: switch tenant_a to 0% without
   redeployment, in seconds.

EDI implementation

Concrete case: deploy the new Walmart 850 mapping v2.0 which supports the carta porte 3.0 complement for the Mexican market. Without Feature Flag: global deployment, risk of regression on all existing US partners. With Feature Flag: the flag features.walmart_850_v2 is deployed inactive. The dispatcher code contains: if (featureFlags.isEnabled('walmart_850_v2', { tenantId, partnerId })) { useV2Mapping() } else { useV1Mapping() }. We activate the flag at 10% for tenant_mexico, monitor SLOs and error rates for 24h. If OK, we move to 100% for tenant_mexico, then to 10% for US tenants, etc. Industrialisation follows the Canary Release pattern. Tools: LaunchDarkly (commercial reference, multi-language integrations), Flagsmith (SaaS open-source alternative), Unleash (full open source). Flags must be ephemeral: after 2-4 weeks at 100% stable, scheduled cleanup to delete the v1 branch from code.

Anti-patterns

  • Immortal flag: 6 months after 100% stable, the flag is still in the code. The if becomes a tech-debt rot pit.
  • Too many flags: 150 active flags simultaneously. Unmanageable combinatorics, impossible tests, unreadable code.
  • Flag in code but not in config: hard-coded as true or false, loses all runtime steering value.
  • Unaudited flag: production change without trace, impossible to trace back to the decision in post-mortem.
  • Flag coupled to a secret: the flag bypasses a security check — dangerous practice to ban.
  • Flag without progressive rollout: all-or-nothing kills half the value of the pattern.
  • Canary Release — progressive rollout directly consumes flags.
  • Blue-Green Deployment — infrastructure variant, complementary to application flags.
  • Dark Launch — variant where the flag activates code without making the output visible.
  • Circuit Breaker — neighbouring runtime-protection pattern, without the rollout aspect.
  • Detour — neighbouring EIP pattern to activate/deactivate optional steps.

Sources

  • Hodgson P. — Feature Toggles (martinfowler.com, 2017). The canonical flag taxonomy (release toggle, experiment toggle, ops toggle, permission toggle) referenced across the literature. martinfowler.com — feature-toggles
  • Rahman M. — Effective Feature Management, O'Reilly 2020 (LaunchDarkly). Operational best practices for driving feature flags at scale.
  • LaunchDarkly — Official documentation of the market leader platform. docs.launchdarkly.com
  • Unleash — Documentation of the reference open-source implementation. docs.getunleash.io
  • Humble J., Farley D. — Continuous Delivery, Addison-Wesley 2010. Chapter 4 §6 (Decoupling Deployment from Release) — the conceptual foundation of the pattern.
  • Beda K., Burns B. — Kubernetes Patterns, O'Reilly 2019 (cf. Burns, Beda, Hightower, Kubernetes Up & Running). K8s rollout patterns that pair with application feature flags.