Beyond Application Code: Extending CI/CD to Configuration, Mobile, and Feature Flags

You have CI/CD pipelines running for your application code, database migrations, and infrastructure provisioning. Deployments are smoother, rollbacks are faster, and your team sleeps better at night. But there is a nagging feeling that something is still missing.

The problem shows up in small ways. A teammate needs to change a database connection string for the staging environment. The fix is trivial - just update a config value - but it requires a full deployment cycle because the configuration is baked into the code. Or your mobile team releases a new version, but the app store review takes three days, and nobody planned for that delay. Or a feature that was supposed to be rolled out gradually to users is either fully on or fully off because there is no mechanism to control it without redeploying.

These are not edge cases. They are the areas where most CI/CD implementations start to show cracks. The good news is that extending your pipeline to handle configuration, mobile apps, and feature flags is straightforward once you know what to look for.

Configuration as a Separate Delivery Path

Most teams start by storing configuration in environment variables or config files that live alongside the application code. This works until it doesn't. The moment you need to change a value for one environment without touching others, you realize that configuration and code have different lifecycle needs.

Configuration changes should not require a build. They should not require running the full test suite. They should not require a deployment that restarts the application. A database connection string, an API key, or a feature toggle value is not code. Treating it like code adds unnecessary friction.

The solution is to separate configuration from code and give it its own pipeline. This pipeline is simpler than the one for application code:

The diagram below shows how the main pipeline branches into three distinct paths, each with its own lifecycle.

For example, a feature flag configuration file might look like this:

{
  "new_checkout": {
    "enabled": true,
    "rollout_percentage": 10,
    "description": "Gradual rollout of the redesigned checkout flow"
  },
  "dark_mode": {
    "enabled": false,
    "rollout_percentage": 0,
    "description": "Dark mode toggle for all users"
  },
  "search_autocomplete": {
    "enabled": true,
    "rollout_percentage": 100,
    "description": "Autocomplete in search bar, fully rolled out"
  }
}

The application reads this file at startup and periodically checks for updates. Changing rollout_percentage from 10 to 50 does not require a build or deployment — the application picks up the new value dynamically.

1. A change to a configuration value is committed to a repository
2. The change goes through the same review process as code changes
3. Once approved, the configuration is applied to the target environment
4. The application picks up the new value without restarting

The key difference is that the configuration pipeline skips the build and test stages. There is nothing to compile or unit test. What matters is that the configuration reaches the right server and that the application can reload it dynamically.

This approach also makes auditing easier. Every configuration change is tracked in version control, reviewed by a peer, and applied through a pipeline. No more SSH-ing into a server to change a value and hoping nobody notices.

Mobile Pipelines Have Different Constraints

Mobile applications look like any other software project until you try to deploy them. The build process produces an installer file that must be digitally signed. The distribution goes through app stores that have their own review processes. And once a version is in the hands of users, you cannot force them to update.

These constraints change how you design the pipeline. The build and unit test stages work the same way as for backend applications. But the deployment stage needs two separate paths:

The first path is for internal distribution. Before sending a build to the app store, your team needs to test it on real devices. Platforms like Firebase App Distribution for Android and TestFlight for iOS let you distribute builds to QA teams and beta testers without going through the app store review process. Your pipeline should automatically upload builds to these platforms whenever a new version is ready for testing.

The second path is for production release. This is where the pipeline submits the signed build to Google Play Store or Apple App Store. The pipeline cannot control how long the review takes, but it can track the status. When the review is approved, the pipeline can trigger the actual release to users.

Risk gates for mobile pipelines need to include checks that are specific to mobile. Certificate expiration dates, signing key validity, and version number increments should all be verified automatically. A build with an expired certificate will be rejected by the app store, and finding that out after waiting for review is painful.

Feature Flags Enable Gradual Rollouts

Feature flags are a mechanism that lets you turn features on or off without deploying new code. They solve a common problem: a feature is complete, but you are not sure if it is ready for all users. Maybe it needs more testing. Maybe you want to roll it out to a small percentage of users first. Maybe you want the ability to disable it quickly if something goes wrong.

Without feature flags, your options are limited. You can delay the deployment until you are confident, which slows down delivery. Or you can deploy and hope for the best, which increases risk. Feature flags give you a third option: deploy the feature in a disabled state, then enable it gradually.

Adding feature flags to your pipeline requires two changes:

First, the pipeline must verify that the code works correctly in both states. When a feature is wrapped in a flag, the tests should run with the flag enabled and disabled. This catches issues where the feature flag logic itself has bugs, or where the disabled state breaks existing functionality.

Second, the pipeline should help you clean up flags that are no longer needed. Feature flags that stay in the codebase forever become technical debt. They add complexity, make the code harder to read, and increase the risk of bugs. A good practice is to add a pipeline stage that checks for flags that have been fully rolled out to all users for a set period, then automatically creates a task to remove them.

Practical Checklist for Extending Your Pipeline

Before you start implementing these changes, run through this checklist to identify what needs attention:

• Can you change a configuration value for one environment without redeploying the application?
• Is every configuration change tracked in version control and reviewed before applying?
• Does your mobile pipeline automatically distribute builds to internal testers?
• Does your mobile pipeline verify certificate expiration and signing key validity?
• Are feature flags tested in both enabled and disabled states?
• Do you have a process for removing feature flags that are no longer needed?

If you answered no to any of these, you have a clear next step.

The Takeaway

CI/CD is not complete when your application code deploys smoothly. It is complete when every change that affects how your software behaves - whether it is code, configuration, or a feature toggle - goes through a controlled, automated, and auditable process. Configuration pipelines remove the friction of environment-specific changes. Mobile pipelines handle the unique constraints of app store distribution. Feature flags give you the ability to control risk without slowing down delivery.

Start with the area that causes the most pain in your team today. For most teams, that is configuration management. Once that is working, move to mobile or feature flags depending on what your team ships. The goal is not to build the perfect pipeline on day one. The goal is to make sure that nothing falls through the cracks.