ra2 studio - Fotolia
Logic dictates that going faster has its dangers – there is a temptation to cut corners, and there is a risk of increasing errors. But with software development, that’s not always the case.
“It might be counter-intuitive, but quality can come from speed,” says Vladyslav Gram, head of DevOps at Ciklum, a bespoke software development and IT outsourcing company. “The faster we develop and deploy, the higher the quality, because we can deploy with relatively smaller portions of code, which are easier to test. Meanwhile, developers get immediate feedback from the production environment.”
Gram started working with continuous integration and continuous delivery (CI/CD) in 2016. An element of the DevOps philosophy, CI/CD is focused on getting code into production as quickly as possible, in contrast with earlier approaches to developing software, including waterfall, which produce larger chunks of code over longer periods, making testing more time consuming and less reliable, he says.
“If we have a huge regression plan for testers, if we have one million features dependent on each other, it's hard to predict which components it will depend on. But if we are deploying only a single small feature, we can test it and can easily predict what the dependencies are,” says Gram.
Pitfalls to avoid when introducing CI/CD
Continuous integration (CI) and continuous delivery (CD) can enable faster iterations, faster time to value for customers, services isolation for debugging, and root-cause analysis, says Shiven Ramji, chief product officer of Auth0, developer of an enterprise identity platform. But he also offers lessons in avoiding pitfalls. His top three recommendations are:
Separation of services. It is critical that you break apart your monolithic app into separate services such that they are isolated and abstracted from each other.
Before you get to CD, make sure you do CI well. There are some foundational elements such as having consistent tooling, libraries and operating system configurations.
Many organisations have tooling sprawl in an effort to get CI/CD right. Make sure you invest in the underlying infrastructure, the correct tooling and have the right metrics in place.
The benefits have been stark, he says. Ciklum has been working with European retailer Metro to build an e-commerce platform and has cut the standard three-month deployment release schedule to one hour to get changes to production.
“The difference is huge, but that doesn't mean we are deploying the same amount of changes every hour that we would release in three months. However, it does mean the developer gets feedback from users and the production environment much faster than on a three-month release schedule,” he says.
Features delivered faster
Jez Humble, a lecturer at University of California, Berkeley, and co-founder of DevOps Research and Assessment (Dora), literally wrote the book on CI/CD in 2010. He defines it as: “…the ability to get changes of all types – including new features, configuration changes, bug fixes and experiments – into production, or into the hands of users, safely and quickly in a sustainable way.”
According to a survey by software testing firm Mabl, 53% of the 500 respondents said they use continuous integration and 25% plan to introduce it. Meanwhile, 38% of respondents employ continuous delivery and 30% plan to do so.
The 2019 Accelerate State of DevOps report, for which Dora surveyed 3,000 developers, found that, comparing the elite group to poor performers, the former achieved 208 times more frequent code deployments, 106 times faster lead time from committing code to deployment and 2,604 times faster to recover from incidents.
Race to cloud
Although they are related, DevOps and CI/CD should not be confused, says Ariane Gadd, lead DevOps engineer at KPMG. “DevOps is more of a culture, a mindset, and a way of working. CI/CD is an approach to orchestration led by tooling and automation. Organisations use CI/CD to implement technology projects in a DevOps kind of way. You can’t do DevOps without CI/CD.”
The rise of CI/CD coincides with the increasing popularity of deployment in the cloud. Although organisations could use conventional development techniques to build software for the cloud, there would be little point, says Gadd.
“You’re not really getting the benefits of the cloud if you are deploying software as you would on-premise. [With CI/CD] you get cloud-native things like optimisation, scalability and elasticity, and performance. If you don’t leverage those, you’ve just got an on-premise solution in the cloud and you are not really leveraging the benefits,” she says.
Culture must turn a corner
One of the difficulties in introducing CI/CD is changing people’s roles as new tools are deployed. Security controls and change approvals were once manual processes, with a person allocated to them. With CI/CD they are automated.
“It is not necessarily telling people we are going to automate you out of a job, but it is saying, ‘Let’s change the way we work’. The trickiest thing is getting all the teams working together so they understand they will not see the process as they have done in the past and they are not going to go through the change board every time they want to implement a change. It is still secure and in line with policy, but it is a question of getting everyone on board, and educating them in the new way of doing things,” says Gadd.
Start slow, build from there
The introduction of CI/CD has not been flawless. For example, half of organisations doing so do not include any security testing elements, according to a 451 Research survey of 350 enterprise IT decision-makers in North America and Europe fielded in May 2018.
Problems can occur when development teams confuse the speed of delivery with a lack of preparation, says Gadd.
“The mistake a lot of people make is they think it is all about building quickly and delivering fast, but they forget to document properly, so nobody knows what they have actually done,” she says.
Gadd recommends investing time upfront in optimising infrastructure and developing the correct scripting. Otherwise teams will have to go back and make changes retrospectively, losing benefits and damaging the reputation of the approach they are trying to promote.
“It takes time at the beginning to automate things and write scripts. But once you’ve got that right, you can repeat it as many times as you want,” she says.
Curb your speed
Cytora has developed a technology platform to help insurance companies underwrite their policies more accurately. Don Tran, director of engineering, began introducing CI/CD about a year ago.
He says the greatest lesson is that it is not all about speed.
“When I started, I thought it was about going super-fast, just unlocking the speed. But it is actually way more important to go as fast as you can right now, but no faster,” he says.
Different development teams will rely on different infrastructure, tooling and be at a different stage in their DevOps journey. If a team gets the cycle down from two weeks to one week, they should see that as progress, says Tran.
“If that’s as fast as you can go right there and then, then good, but you can iterate on that and move up to the next level,” he says.
“Teams that go too fast before they are ready just break things faster, and they don't get fixed. It's definitely about going as fast as you can, but no faster. That's the biggest lesson I've learned,” he says.
The right tools
As teams’ understanding of CI/CD improves, so does the tooling. This ranges from generalist collaboration software such as Slack, to technical tools such as Pivotal Concourse, which helps developer teams design workflow for modular components.
For all its increase in popularity, CI/CD has a long way to go before it becomes the de facto method of software development, says Tran. “Software developers are converging to using a lot of the things that come out of continuous delivery. But enterprise IT is all-encompassing and pretty big, and this concept is still very new. It’s early days.”
CI/CD promises a phenomenal acceleration of software development speed compared with traditional methods of building software. But teams considering the approach must educate developers, change the culture among the wider IT teams, and invest in tooling and infrastructure to reap the benefits.