Change the Development Culture

Once you’ve avoided the pitfall of the "DevOps department," you face a new foundational challenge. The folks with operational expertise are ready to mingle with the team, automating deployments, configuration, and monitoring, but is your development culture ready for that mingling?

One of the biggest mistakes from the early days of agile revolved around not changing the technical practices. Software groups used to shipping software on a yearly basis were in for a serious culture shock. Agile methodologies generally demand that you ship once every few weeks. This resulted in a lot of awkward, halting, and failed adoptions of agile, in which the team just wound up having slightly different meetings.

You face the same conceptual issue with DevOps. Collectively, as an industry, teams have automated elaborate deployment pipelines, allowed scripted, on-demand configuration of environments, and gotten monitoring technologies down to a science; however, to leverage all of that, they need code that exists in a perpetually deployable state, a mistake that many shops have not realized.

If you’re used to having days or weeks between deployable versions of your code, all of the DevOps in the world won’t help you. It would be like pulling up to a nice, smooth road with a car that has no gas. Before adopting DevOps, make sure you’ve matured your development culture.

Avoid Long-Lived Feature Branching

In some ways, this mistake is a more specific version of the previous topic, but it’s worth calling out separately because that’s not always the case.

In the broadest terms, you have two collaborative workflows at the end of a spectrum: trunk-based and feature-branch-based development. Trunk-based development means that developers work at all times in a mostly coherent, single version of the codebase. Feature-branch-based development means that the team works in a way that gives individual features their own, isolated sandboxes.

Going into the pros and cons of each approach is beyond the scope of this article, but I will speak to what they mean for your DevOps adoption efforts. Source control tools have an outsized effect [5] on which approach you adopt, just as your approach has significant ramifications for DevOps as a methodology.

If you favor feature-branch-based development, you’re going to suffer a lot of pain with DevOps adoption. DevOps automates many aspects of how you treat your code between developers’ machines and production environments. Keeping many different conceptual flavors of your codebase around makes DevOps concerns an order of magnitude more complex.

Make your life easier by migrating toward a trunk-based workflow.

Adopt Granular Codebase Instrumentation

To conclude, I’ll talk about something you’ll probably only face once you've done well with the previous three tasks, because this mistake occurs once you have successfully adopted the practices and are moving code around between your environments with ease.

With this issue, you fail to realize all that you can get out of your new capabilities. You move your builds around with ease, but you move them around as monoliths. This is a mistake, because you lose track and control of new features.

With trunk-based development, you stop managing features through version control and start managing them through selective deployments [6], which you achieve the way companies like Facebook do: with a feature flag management system [7]. Doing this lets you configure not only operational data but also entire sets of features and the user experience.

To achieve the most flexibility with production concerns, you need to alter your codebase. Make sure it’s flexible, conceived in granular fashion, and easily partitioned, because DevOps isn't just about automating how you deploy things – it's about automating how you handle them once they're deployed.