GitLab CI: Feature flag pipelines

Ever been in a situation where you need to test a risky new feature in production without breaking everything? Or maybe you've had to coordinate a complex rollout across multiple teams, praying nothing goes sideways? That's where GitLab's feature flags come in - they're basically safety switches for your CI/CD pipeline.

Think of them as toggles that let you turn features on and off without redeploying code. You can test beta features with specific users, manage breaking changes gracefully, or just experiment without the usual anxiety. Let's dig into how they actually work and why you might want to use them.

Introduction to feature flags in GitLab CI

Feature flags in GitLab Runner are environment variables that control specific features in your pipeline. Pretty straightforward concept, right? But here's where it gets interesting: they let you take calculated risks with incomplete features while keeping your main pipeline stable.

The beauty is in their simplicity. You can apply flags globally across all jobs or target specific ones. Need to test that experimental parallel processing feature? Flip a switch. Want to gradually transition from old to new behaviors? Feature flags have you covered.

To turn a flag on, you just set the environment variable to "true" or 1. Turn it off with "false" or 0. The GitLab Runner documentation lists all available flags with descriptions and deprecation timelines - definitely worth bookmarking if you're serious about this stuff.

Just remember: with great power comes the potential for data corruption and stability issues. Not trying to scare you, but it's worth being careful when you're essentially running beta features in production.

Activating and configuring feature flags

Setting up feature flags is dead simple. You've got two main approaches:

1. Global configuration: Set them for your entire pipeline

2. Job-specific configuration: Target individual jobs in your CI/CD config

This flexibility is huge. Say you're rolling out a new caching mechanism - you might want to test it on your less critical jobs first before going all-in. Or maybe you're dealing with a breaking change that only affects certain workflows. Feature flags let you be surgical about your rollouts.

The real win here is how they handle transitions. Instead of forcing everyone to adapt to changes overnight, you give teams breathing room. They can toggle between old and new functionality while they update their processes. It's especially handy when you're introducing something that might break existing workflows.

But let's be real about the risks. When you activate a flag, you're potentially opening yourself up to:

• Performance hits (that new feature might not be optimized yet)

• Data integrity issues

• Security vulnerabilities in beta code

• General weirdness and unexpected behavior

The key is thorough testing and monitoring. Watch your metrics like a hawk when you flip that switch. And honestly? Start small. Test with a subset of jobs before going wide.

Exploring key feature flags in GitLab CI/CD

Let's talk about some feature flags you'll actually use. FF_NETWORK_PER_BUILD is a personal favorite - it creates an isolated Docker network per build. Why should you care? Because running concurrent jobs in the same network is asking for trouble. Port conflicts, security issues, general chaos - this flag prevents all that.

Another useful one is FF_USE_DIRECT_DOWNLOAD, which comes enabled by default. It lets your jobs download artifacts directly instead of routing through GitLab. The performance boost is noticeable, especially if you're dealing with large artifacts or high-traffic pipelines.

Then there are flags for managing deprecated features. FF_SKIP_NOOP_BUILD_STAGES is a good example - it skips build stages that literally do nothing. Sounds obvious, but you'd be surprised how many pipelines have these vestigial stages hanging around from previous iterations.

The real power comes from combining these flags strategically. Maybe you enable network isolation for your security-sensitive jobs while keeping direct downloads for speed. Or you might use deprecation flags to gradually phase out old behaviors without breaking existing workflows. It's all about finding the right balance for your specific needs.

Best practices for using feature flags in pipelines

Here's the thing about feature flags: they're not a silver bullet. Use them wrong, and you'll create more problems than you solve. But get them right? They'll transform how you manage your CI/CD pipelines.

Start with the basics:

• Test flags in non-critical environments first

• Monitor everything - response times, error rates, resource usage

• Document which flags you're using and why (future you will thank present you)

• Have a rollback plan ready

The team at Spotify learned this the hard way when they rolled out a new build optimization flag to their entire pipeline at once. Performance tanked, builds started failing randomly, and they spent a weekend firefighting. Now they use a staged rollout approach - 10% of jobs first, then 50%, then everything.

Keep your flag usage lean. It's tempting to have flags for everything, but that creates its own complexity. Focus on flags that actually add value:

• Testing risky features

• Managing deprecations

• Controlling rollouts

• Emergency kill switches

And here's something people often miss: feature flags aren't meant to be permanent. Once a feature is stable and widely adopted, remove the flag. Otherwise, you end up with a graveyard of old flags that nobody remembers the purpose of.

If you're using Statsig alongside GitLab, you can actually coordinate feature flags across both platforms. It's pretty slick - you get GitLab handling the pipeline-level flags while Statsig manages the application-level ones. The Netflix engineering team uses a similar setup for their continuous delivery pipeline, and it's saved them countless hours of coordination headaches.

Closing thoughts

Feature flags in GitLab CI/CD are one of those tools that seem simple on the surface but can fundamentally change how you approach deployments. They give you the confidence to experiment, the control to manage risk, and the flexibility to adapt as requirements change.

The key is starting small and being intentional. Pick one risky feature or breaking change you need to manage, implement a flag for it, and see how it goes. Once you get comfortable with the workflow, you'll find yourself reaching for feature flags more and more.

Want to dive deeper? Check out the official GitLab Runner documentation for the full list of available flags. And if you're looking to extend feature flagging beyond just your CI/CD pipeline, platforms like Statsig can help you manage flags across your entire application stack.

Hope you find this useful!