The 7 Spices of a Continuous Delivery Pipeline
A Continuous Delivery pipeline as part of an Agile transformation is like spices in a meal. Without them, the food is bland and worthless. On the other hand, the right blend of spices will leave you craving more, stimulating your senses and energizing you. But as any good cook will tell you, it can be a bit difficult to find the exact right blend of spices for a specific dish.
Salt and pepper are usually basic requirements, but knowing how to give your creation a boost by adding more complex spices, like turmeric, star anise, ginger or coriander, is a little trickier. It requires selecting the spices with care to make the dish tasteful—and that’s exactly like choosing tools for your CD pipeline and building your pipeline up. In short, creating a Continuous Delivery pipeline is not like using a standard set of spices you store in your kitchen drawer. You must carefully choose your tools per the goals of your team.
Want to become the master chef of your Continuous Delivery pipeline? Here are 7 tips:
- Avoid creating monoliths
- Strike a balance between fixed and flexible components
- Treat your CD Pipeline as a value stream, not a bunch of tech tools
- Use the MVP approach to build and extend your pipeline
- Embrace a model that allows you to easily experiment
- Limit the number of homegrown solutions you build—don’t miss out on all the great tools already on the market
- Setup your CD pipeline like it’s your most critical piece of software
Avoid Creating Monoliths
Monolithic applications can be a useful part of backend operations. But as you increase your customer-facing applications and interactions, monoliths become difficult to handle, impeding and restricting agility. Keep in mind that most of the changes you’ll experience over the next few months and years will probably affect the monoliths. Tools grow and go, new frameworks force you to adapt, and compliance is no longer a department, but more like oxygen—it’s everywhere and crucial to surviving. You need to accept that, in increasingly agile environments, monoliths are a thing of the past, and should be avoided as you create your CD pipeline.
Strike a Balance Between Fixed and Flexible Components
Every IT team in every organization whether, insurance, government or banking, faces mandatory requirements. My advice is to set up a pipeline with a dual focus.
First, create fixed processes for addressing elements of the pipeline that are mandatory for getting software into production. Examples include version control, 4-eye principle, peer review, secure code review and user access management. Think of this as the salt and pepper of your delivery process—it’s the foundation of a tasty dish.
Next, make all non-mandatory processes flexible by using a modular approach. Allow teams to choose from a set of OP tools that can be easily attached to the pipeline. Not every team, for example, requires the same performance test tool. Depending on the technology, type, moment and maturity of testing, you could give let them select from, say, a set of five tools. This gives them freedom of choice while allowing you to maintain control and reduce maintenance.
Treat Your CD Pipeline as a Value Stream, not a Bunch of Tech Tools
CD pipelines require care and feeding to keep them running at peak efficiency. You can’t just pull together a bunch of tools and watch your pipeline magically transform. Your pipeline is better seen as a value stream that allows you to visualize your release process, understanding its throughput times, identifying bottlenecks and so on, so you can continually optimize your delivery cycle. The shorter a release is from “Merge to master” to “Deployment in production,” the faster feedback will flow throughout your organization, and the better your ability to respond quickly to last-minute demands.
Use the MVP Approach to Building and Extending the Pipeline
Building a CD pipeline is hard work. Don’t expect to create it overnight or to onboard teams in the blink of an eye. Start small and grow with the maturity of the team. It’s like learning to cook great meals. You might start by buying some pre-packaged seasonings from the supermarket and adding water. The more knowledgeable you become, the better you get at picking your own spices, which gives you the confidence to start experimenting. Why? Because you come to understand the subtleties of flavor and the effect of certain combinations.
Embrace a Model that Allows for Experimentation
Speaking of experimenting, if you want to become an Agile organization, your CD pipeline should be flexible enough that you can try new things. Let’s be honest, tools in this field are like Roman emperors: they rise, shine and fall, so you must be able to experiment without breaking things. For example, if you balance your pipeline between fixed and flexible components as suggested above, you could try using multiple Docker containers without destabilizing the pipeline.
Limit the Number of Homegrown Solutions You Build
With all the great tools on the market, there’s no need to start building your own CD tools. You can create robust pipelines that fit into the above principles using off-the-shelf tools.
Setup Your CD Pipeline like It’s Your Most Critical Software
From time to time I still hear people say that, when faced with urgent business demands, they skip over the pipeline and place software directly into production. The argument is that the pipeline is simply too slow to meet the demand. Here’s what I suggest:
- Make your pipeline stable enough to work in every critical situation
- Ensure that the pipeline extends from end-to-end so you can optimize all activities towards getting working software into production
- Make the pipeline fast enough so you’re not tempted to do everything manually
Achieving availability, integrity, reliability, and speed is definitely hard work. But if you structure your pipeline as suggested with both fixed and flexible parts, it will be a lot easier to start small and grow into a highly efficient Continuous Delivery pipeline.
This post originally appeared on the XebiaLabs Blog.