This is a brief description of feature flags (also know as feature toggles or feature switches) used in combination with version management and branching strategies to streamline and optimize CICD pipelines.

1. Feature Flags
Feature flags (also referred to as feature toggles or feature flippers) act as run time switches to turn on or
off user access to specific features. They allow you to control access in real-time with no code
deployments necessary.
You can choose to grant or block access based on all sorts of criteria such as user access controls, user
groups, time of day, geography, or randomize access for running experiments.
Used in combination with software version management and branching strategies, feature flags are a
very powerful approach to optimize CICD pipelines.

2. https://theproductmanager.com/tools/best-feature-flag-software/
https://theproductmanager.com/topics/feature-flag-management/
https://harness.io/blog/feature-flag-management-tools/
https://www.flagship.io/feature-flag-implementation/
https://harness.io/blog/architecting-feature-flags-performance/
https://www.cloudbees.com/blog/how-to-secure-your-feature-flag-based-application
https://flagsmith.com/
https://theproductmanager.com/tools/best-feature-flag-software/
https://theproductmanager.com/topics/feature-flag-management/
=

3. 3
Feature Flag Use Cases
• Dependency testing – Turn on feature versions for version
compatibility testing during each stage of the value stream.
• Testing in production – Features are turned on in the production
environment for testing by specific internal users.
• Feature enablement – Features are enabled for certain entitled
users.
• Testing in Production – Selected customers participate in feature
trials.
• Gradual Release rollout – Features are turned on gradually to
more users until fully deployed.
• Roll-back – Switch back to earlier version if problem detected
• A/B Testing – Test with different switch settings to compare
results.
• Feature experiments – Turn on a feature to test hypothesis.
• Feature demonstrations – Turn on a feature to demonstrate to
selected group of stakeholders.
• Kill-Feature Switch – Monitoring system triggers feature switch
off.

4. 4
Simple Code Switch
E.g., if/else
statement
Usually reserved for
short-lived flags.
Maintenance issues
when supporting
many feature flags.
Config File
(In-house solution)
Config file controls which
code path will be enabled.
Cost of maintaining in-
house tools.
Accumulation of technical
debt.
Feature Flag Management
System
(3rd Party Solution)
Lifecycle management of
feature Flags.
Third-party tools (E.g.,
Unleash, Flagsmith,
LaunchDarkly, Hackle, Split,
CloudBees, Harness, …)

5. 5
• Access controls - custom permissions restrict who can make changes.
• Audit logs – track which features are enabled and tested.
• Environment-sensitive configurations - E.g., development and production environments
• Meta data - Feature flags can be tagged with meta data to support search.
• Dynamically controls - context-specific flagging decisions E.g., trigger on a user basis.
• Track Flag usage - to determine which can be removed if no longer used.

7. 7
1. Identify priorities of feature flag use cases.
2. Start Feature Flag implementation by testing one simple use case and
simple switch before evolving to more advanced implementations.
3. Decide whether to use in-house or a third-party solutions. Solution
choice decision factors include Ease of use, Stability, Scalability,
Flexibility, Support cost, License cost, Tools compatibility, and
Language compatibility.
4. Build a Feature Flag MVP for a model application, monitor usage and
expand to other applications and use cases.