The C’s in CI/CD stand for continuous, but they might just as well refer to culture, because you can’t treat CI/CD solely as a technical strategy. Culture is just as important to its long-term success.
First off, though: What is CI/CD? (We’ll paraphrase, but click through that link for a more complete breakdown.) CI/CD can mean different things to different people. CI stands for continuous integration, and it involves building, testing, and merging developers’ various code changes into a shared repository such as Github or a container registry, usually multiple times per day.
CD, on the other hand, refers to either continuous delivery or continuous deployment, which are sometimes used interchangeably. Either way, this typically refers to later stages of the software pipeline, and especially to how new code moves into production.
CI/CD is commonly thought of or visualized as a pipeline, and no matter a particular person’s or organization’s definition, CI/CD involves increasing the degree of automation in that pipeline to help support the “faster, better, more frequent” ethos of DevOps – and modern software development in general.
“Fundamentally, succeeding with CI/CD requires transitioning from a process that is very manual and slow in many organizations to one that is much more automated and rapid,” says Red Hat technology evangelist Gordon Haff. “Some companies can end up going from one or two releases per year to a release of one or more per week or even per day.”
[ How does CI/CD fit with your need for development speed? Read DevOps success: Why continuous is a key word. ]
Like DevOps itself, though, there’s no magic wand you can wave en route to CI/CD success. And again, CI/CD is not simply a matter of technology; its long-term success depends on a healthy culture. If you’re just starting out, here are four key factors to keep in mind.
1. Don’t treat CI/CD as a project or a purchase decision
While you might pilot a particular app or add new tools as part of a move to CI/CD, don’t confuse either one as the end goal.
“You don’t buy CI/CD, just as you don’t buy DevOps,” Haff says. “CI/CD benefits from the right tools, but if they’re not used as part of a complete end-to-end process that is committed to rapid iteration, the initiative will not deliver the expected benefits – or it will outright fail.”
There are certainly important technical choices involved in CI/CD. But a good tool won’t convince a reluctant team or patch broken workflows on its own.
“This is a journey because CI/CD is really a lifestyle choice, not software you buy, configure, and use,” says Robert Reeves, CTO and cofounder at Datical. “You are choosing to automate every aspect of your software delivery process, and that must be iterative. You will be identifying areas that are manual and working to automate them.”
We’ll get to the importance of long-term planning (which should be viewed as a sign of a healthy culture, not antithetical to a healthy culture) in a moment. In the meantime, the term “iterative” is particularly meaningful.
If you’re moving from a highly manual pipeline to a more automated one via CI/CD, prepare to work in stages. You can choose your metaphor or adage here (don’t boil the ocean, eat the elephant, Rome wasn’t built in a day, etc.) but the principle remains the same: Pick a finite starting point and grow from there.
Mike Bursell, chief security architect at Red Hat, says that it shouldn’t be too hard to find at least a small group of enthusiasts, likely a mix of developers and some operations and testing pros, to run a proof of concept. That’s one example of a potential starting point. Recognize that it’s indeed that: Just a start.
[ Read our related article: 3 new DevOps lessons learned, by Robert Reeves. ]
2. Plan. Then, plan some more
Bursell notes that bottom-up, organic movement toward CI/CD can be great – leading to, among other benefits, higher levels of enthusiasm for CI/CD. Just don’t use “organic” as a cover for “haphazard.”
“If CI/CD is to succeed within your organization, you need to do some planning,” Bursell says. “In fact, if you plan ahead a little, and ensure that these [early] projects include more than just the bare minimum of enthusiasts, the longer-term future for CI/CD in your organization looks much more healthy.”
Bursell recommends those early projects not be limited solely to developers eager to move their code faster through the pipeline and like-minded Ops and testing practitioners.
“Make sure you have some UX people, documentation folks, and definitely some product owners and business minds: People who are actually going to be consuming the output of the project,” Bursell says. “That way, you’ll actually learn a lot more from the first project or two – whether they fail or succeed – and will be in a much better position to try a number of recipes for CI/CD.”
Some of your planning will be technical in nature. Haff notes that there is some heavy lifting up front in terms of having the right platform, monitoring, and testing in place. He also notes that part of your long-term plan may involve refactoring existing applications so they’re more amenable to being updated in chunks rather than all at once. It’s a lack of this kind of planning that might indicate underlying cultural issues; if the plan is simply “we’ll figure it out later,” something may be amiss.
While a CI/CD initiative can certainly start small, or start with a small interdisciplinary team, it’s long-term success will also need full support from IT and business leaders, especially as the initiative spreads. This will be key when there are decisions to be made that may pit keeping the lights on against the longer-term CI/CD learning process that will generate future benefits for the whole company.
“It requires high-level executive buy-in,” Haff says. “You’ll be making investments today for improvements in your application development speed tomorrow.”
