37 lines
1.6 KiB
Markdown
37 lines
1.6 KiB
Markdown
---
|
|
title: >
|
|
Feature flags enable continuous integration
|
|
pubDate: 2023-09-28
|
|
permalink: >-
|
|
daily/2023/09/28/feature-flags-enable-continuous-integration
|
|
tags:
|
|
- software-development
|
|
- git
|
|
- continuous-integration
|
|
- feature-flags
|
|
---
|
|
|
|
I was recently working on a feature over a few mob programming sessions.
|
|
|
|
After the session, we implemented part of the feature but couldn't merge it as it wasn't complete.
|
|
|
|
After working on other things that day, I'd need to rebase my local commits and push the last-but-one commit to the remote repository to keep the incomplete feature only in my local repository (I forgot a few times and almost pushed it accidentally).
|
|
|
|
The commit prevented me from following continuous integration - where everyone commits and pushes their code a minimum of once daily.
|
|
|
|
What if someone else wanted to look at that code between mob sessions? They couldn't, as it was only on my laptop.
|
|
|
|
If I'd made a temporary branch, it would be outdated and behind other changes to our mainline branch.
|
|
|
|
## Feature flags to the rescue
|
|
|
|
As this commit was part of a larger change, it couldn't be merged, so we added a feature flag around it.
|
|
|
|
The values were set to null and hidden by default, and populated by the new changes and displayed if the flag was enabled.
|
|
|
|
## Here's the thing
|
|
|
|
This meant we could safely push the commit, make the changes available to everyone and enable the feature on the environments we wanted - preventing it from showing on production.
|
|
|
|
This allowed us to get back to our usual working practices, and I didn't need to worry about accidentally pushing the commit and prematurely showing our changes in production.
|