When I asked LinkedIn about the challenges of incremental software delivery, Nick Halm wrote a great response:

Making feature toggles and trunk based development the norm.

Feature toggles are often misunderstood to be for front ends only. That is absolutely not the case. It is very possible to put all development behind a feature toggle. Logging and tracing can now include the toggle evaluation outcome and your team is set up to measure the success of the changes very easily. The toggles also empower teams other than engineering to run their test/campaigns when it makes sense for them to do so.

Once feature toggles are leveraged there is a clear path for trunk based development. If your strategy is to merge directly to “main”, teams tend to make much smaller changes more rapidly. If something goes wrong you don’t need a special hot fix procedure because you can just push your change to “main” and deploy in no time.

I usually coach teams to implement trunk-based development (TBD) early on, but there’s a lot to be said for implementing feature flags first. One of the most common questions I’m asked when describing TBD is “How do we handle a big feature that’s not ready yet?”

And of course, feature flags, is the simple answer. And even without some big fancy framework, you can always use the poor man’s feature flag.

If you’re a bit new to the concept of feature flags/toggles, I encourage you to listen to my interview with Joy Ebertz of Split, as she talks about the benefits of feature flags, and how easy it can be to get started. Check it out in Episode #36 of the Tiny DevOps Podcast.