Feature Flags in CI/CD: Automate Flag Lifecycle with the Featureflow API

If your CI/CD pipeline deploys automatically but a human still has to log in and flip a flag to finish the release — your pipeline isn't automated. It's automated up to the last step.

This is more common than it sounds. Teams adopt feature flags for safe releases, then bolt the toggle step onto the end of the deployment as a manual task. Someone gets paged. Someone forgets. The flag stays off for three days because the engineer who deployed went on holiday. The "release" never actually happened.

Flags Belong in the Pipeline

The fix is straightforward: treat flag state as a deployment artifact. Your pipeline creates infrastructure, runs migrations, and updates config — flag lifecycle is just another step in that sequence.

In practice, there are two patterns worth knowing:

• Enable on successful deploy. After a green deploy to staging, automatically enable the flag for the staging environment. After a green deploy to production, enable for an initial percentage of users.
• Disable on rollback. If the pipeline rolls back a deploy, the flag should roll back too — automatically, not manually.

Using the Featureflow API in a Deploy Script

Featureflow exposes a REST API for managing flag rules programmatically. Here's a TypeScript deploy-step that enables a flag for a given environment after a successful build:

// scripts/enable-flag.ts
const FEATUREFLOW_API = "https://app.featureflow.io/api/v1";

async function enableFlag(
  apiKey: string,
  flagKey: string,
  environmentKey: string
): Promise<void> {
  const url = `${FEATUREFLOW_API}/features/${flagKey}/rules`;

  const response = await fetch(url, {
    method: "PUT",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      environment: environmentKey,
      enabled: true,
      rules: [{ split: 100 }], // 100% rollout
    }),
  });

  if (!response.ok) {
    throw new Error(`Failed to enable flag: ${response.statusText}`);
  }

  console.log(`Flag '${flagKey}' enabled in '${environmentKey}'`);
}

// Called at the end of a successful deploy step
await enableFlag(
  process.env.FEATUREFLOW_API_KEY!,
  "new-checkout-flow",
  "production"
);

Wire this into your GitHub Actions workflow, your Jenkins post-build step, or your deployment script. The flag enable happens atomically with the deploy — no human in the loop.

Start at 5%, Not 100%

The real power here isn't just automation — it's combining automation with progressive rollout. Instead of instantly enabling to 100%, your pipeline enables the flag to 5% on deploy, then a second job runs 30 minutes later to check error rates. If they're clean, it expands to 50%, then 100%.

This is canary releases with no extra tooling — just the flag API and a couple of pipeline steps.

One Thing to Get Right: Environment Isolation

Flag state is per-environment in Featureflow. Enabling a flag in staging does not touch production. This matters when you're automating: your staging pipeline step and your production pipeline step should use different environment keys — and both should use short-lived API keys scoped to those environments only. Treat them like any other secret in your pipeline.

Feature flags give you safe releases. Automating flag lifecycle gives you safe releases that don't require human intervention to complete. That's the full loop — continuous delivery, not continuous deployment-then-wait.

👉 See the full Featureflow API reference at docs.featureflow.io, or get started at featureflow.com.

#FeatureFlags#CICD#ContinuousDelivery#DevOps#Automation