Decouple Delivery from Release to Enable a Fast Continuous Integration Feedback Loop (Video)

Continuous integration is a proven, pragmatic way to give software teams critical feedback. Not only is it important to be building the right thing, but we must also be building it right. Decoupling delivery from release helps teams maintain a fast, continuous integration feedback loop, even during large multi-team efforts. It’s a valuable skill to rapidly deliver updates to production that support new upcoming features without interfering with other parallel development work. Let’s look at an example involving a third party PaaS integration spanning several development cycles.

This is just one of the several foundational software development scenarios covered in our BuildRight Software Sustainability Workshop. We’d love to see you there!

Key Takeaways

Continuously Integrate Knowable Pieces

Resist the urge to deploy all the changes needed to support a new feature in one single delivery. In larger efforts, this will likely include several moving pieces and carry a sizable risk. Instead, determine what changes need to be made and work them into the mainline code in discrete, manageable chunks within the team’s existing development cycle.

Tackle the Non-Breaking Changes

Find the order in which the evolution can proceed. Several strategies can facilitate this. However, one invariant is to have reliable feedback in several forms such as unit tests, component tests, integration tests, and acceptance tests—preferably with automation driving the bulk of them.

I mention the Mikado Method as one of my go-to tools when discovering an effort’s dependencies. It helps me to organize tasks and attack them in an order that always allows our team to deploy. Plus, the nice visual generated helps communicate the plan with other team members and clients.

Latent Code is Okay in Production

Feature toggles (or feature flags) are a very effective tool to shield users from a feature release in the making. Several variations of such toggles address common predicaments one faces with deploying software into a production environment that is not yet intended for consumption by its target audience.

For this talk, we identified the need for a release toggle. Combined with an initial dark launch for our new components, this allowed us to dedicate a deployment to production that involved “switching on” our new feature and nothing else. A release toggle also simplifies testing since its state is not changed once in production. Therefore, our test activities didn’t have to include all the permutations of potential execution paths for the app. If we needed to turn the feature “off,” then we would create a new release. This also had the benefit of capturing the state of toggleable features in our repository.

We chose to implement our own toggling infrastructure, but third-party tools do exist. Certona and LaunchDarkly.com come to mind as examples. There are many.

Have Fun Building Fast

Creative solutions can flow when the stakes are low. But in high stress situations, evolutions can be overly conservative, code can become far beyond defensive, and tech debt continues to fester. Shorter lived branches and more frequent integrations give a team survivable experiments through which to clarify their understanding and refine their solution. This reduces the chance of building the wrong thing.

Build the Thing Right

I’m sure that several developers have been part of an effort to expand their project’s behavior after it has enjoyed seeing the light of day in production. That’s great! That next proposed feature already has to be broken up into smaller-sized chunks. Go the extra distance to make sure each of those chunks is production-ready in order to decrease development risk, keep feedback loops tight, and give stakeholders confidence—not only will the team be building the right thing, they’ll also be building the thing right.