The Advantages of Flags-As-Code

As organizations are speeding up and scaling their software development to match the needs of the modern consumer, they are focused on doing so without losing visibility, traceability, and auditability. These are things, that while slower and more cumbersome, had previously helped prevent bugs and problems from becoming prevalent in software projects.

Developing things "-as-code" allows for engineering to move as quickly as possible while still leaving an extremely granular trail of traceability using their favorite tool - git! You treat all of your application configurations as version artifacts.

Flags-as-code is no different - it can be one of those application configurations. By creating and provisioning feature flags as pieces of code in a config file you gain all the benefits of Infrastructure-as-Code, Configuration-as-Code, and the entire movement.

We're actually checking in our Feature Flags as part of our configuration files in our git server. This allows you to run your Flags-as-Code inside your pipelines, treating it like any other change to application code - subject to normal testing and gates (automated or manual). It looks something like this:

flag: default.followingView
type: experiment
name: following view
conditions:
  - group:
      name:
        - QA
        - Beta Users
    version:
      operator: semver-gte
      semver: 3.0.1
    value: true
value: false

Flags-as-code allows everyone in your engineering organization to see changes made to configurations and flags in the Git Repository of choice - giving the entire team insight into feature flags strewn about inside code.

Because Flags-as-Code is traced through a versioning system like git, you can see who made changes to your feature flags at precisely what time. When organizations have hundreds of flags across many developers - traceability becomes paramount to decrease mix-ups and increase safety during rollbacks.

Checking in your Flags-as-Code alongside your application code and config files allows you to run automated tests against it in your pipeline like you would any other piece of code. This allows you to push fewer bugs and errors to users, especially as your feature flag use scales.

Flags-as-Code works really well with multiple environments, allowing you to easily promote builds between different staging and development servers without losing where you stand on feature flags.