Continuous delivery steps into the spotlight
Continuous delivery is stepping out from the shadow of its partner, continuous integration, and is having a moment as organizations look to increase the speed of application delivery while still delivering stable software.
There is a problem, however. A recent “State of Continuous Delivery” report by the Continuous Delivery Foundation (CDF) found that adoption is low, and less than what was reported in earlier studies, according to Tracy Miranda, the foundation’s director.
Continuous delivery grew out of the DevOps concepts as a way to make changes quickly and get them out to customers, to take advantage of market changes or to outmaneuver competitors. But today, CD (as it is known) has grown to encompass testing, security and governance — basically, all the steps software always has gone through before it is released into the wild.
Taking a step back
As the twin notions of being able to make changes to software quickly and then deliver it to users safely and securely were fleshed out, the terms CI and CD were seen as a pipeline for software production, and were lumped together as CI/CD. But even early on, there was confusion over the meanings of ‘delivery’ and ‘deployment.’ According to Miranda, “For a long time, people saw them as connected. And now we’re starting to get really fine-grained. So you can deploy something into production, but you haven’t delivered it to customers.”
RELATED CONTENT:
The state of CI/CD
DevOps for mobile applications
How CI/CD providers help organizations deploy speedily, securely, and stably
A guide to CI/CD tools
Viktor Benei, CTO and co-founder of mobile DevOps solution provider Bitrise, said continuous integration and delivery are intertwined. “I think it’s part of the same process and trend: automating as many of your processes as possible — anything that can be automated throughout the app development life cycle,” he said. “Reduce manual, error-prone steps via automation and save time for the things which can’t be automated.”
Yet, Miranda believes the term CI/CD is a bit of a misnomer, because it makes you think there are only two things you have to do to deliver software: integration and deployment. She said one of the first things that got discussed when the foundation was being created in 2019 was being able to agree on what is meant by those terms, so there would be a common language to build on. She said they now use the term continuous delivery to mean the set of practices teams need to use to deliver software safely, reliably and securely.
“It’s pretty much in line with the “Accelerate” book Jez Humble and Nicole Forsgren (of the DevOps Research and Assessment team, or DORA) put together,” Miranda said. “We distinguish it from continuous deployment, which is that last stage of getting your code out into production and lots of people use continuous delivery and continuous deployment synonymously. But we prefer to use continuous delivery as the set of practices. So that includes continuous integration, continuous deployment, configuration management, security, and testing.”
Senthil Nathan, product manager, HCL Software DevOps, defined things this way: “I would say the answer is continuous delivery is getting to the end customer, and continuous deployment is more of automating the deployment process.”
CI, he said, can be viewed as a single-pipeline build/unit test environment. “Let’s say checking into master is your trigger. The moment that trigger happens, it goes through different things, but it all happens in, say, a span of minutes.” Organizations have done better with CI than CD, he opined, “because to an extent, that is just live work. Developers pick it up, and they do it.”
On the continuous deployment side, more than developers are involved — you have testers, security people, audit and governance people — and that makes the process more complex. And Nathan said automation is key to replacing manual and scripted deployments, to smooth out and speed up the process.
A manual approach requires changing scripts when moving from, say, a development environment to a staging environment to the production environment. In those non-automated organizations, Nathan explained, “they have a script and they run it out and that does the deployment. But for every new environment that comes up, they change the script to adapt to that environment. So from there, we would like to move them to somewhere where they have a single process that they use to deploy in the dev environment to your production environment. And anything that is different from that environment is more of a configuration and not an actual script change for you to do that.”
Nathan suggests that the first step companies need to take for continuous delivery is to write down their deployment process, which he said is more of a flow chart. “You drag and drop things and then configure it and say, ‘Okay, this is what I want to do as deployment.’ He went on to say organizations should test their deployment processes across environments before the code reaches production. “Then,” he said, “that’s the same thing that you use across all your environments and, if possible, template it and use it across teams, so that each team doesn’t have to reinvent the wheel.”
Still, adoption lags
Part of the reason that CD adoption lags is that many organizations believe what they’re doing today works for them. If scripted deployments work for them, they won’t feel an urgency to change. “It’s more of a denial mode at this point,” Nathan said. “Many of them really think that what they have today is good enough, and they don’t have to pick something new.”
Another piece to the adoption lag is that operations teams have trouble giving up control to the CD tools to do deployments, Nathan added. Where CI is mostly developer focused, CD involves more people, and thus requires more people to agree to doing it. “You need the test teams to come back here and say, I will do test. Like, once the deployment is over, the deployment tool will trigger the testing and all that you need, you need your operations teams to come and agree to whatever we are doing up here. And then you start talking about controlled environments like production and pre-production and things like that, then people say, like, ‘No, this works worked for us for decades, why change that.’ So that is the challenge.”
From continuous delivery emerges progressive delivery
Newcomers to continuous delivery have been confused by the idea, conflating it with continuous deployment, and that has led to people working in the space talking at cross-purposes.
The CDF’s Miranda said, “I think that’s a new evolution, where for a long time, people saw them as connected. And now we’re starting to get really fine-grained. So you can deploy something into production, but you haven’t delivered it to customers. And the term progressive delivery, I think, captures that movement to disconnect deployment, from something that goes to the end user.”
This decoupling of deployment and delivery is largely due to the additional services required to rapidly get new software into the hands of customers. And that has led Miranda to characterize software delivery as a “team sport.”
Delivery, she said, cannot just be left to operations people. Miranda said: “Developers need to have the awareness. Ops people need to be involved. And then you need these specialized skills, you need to bring in your security folks, you need to, if you’re in a highly regulated industry, bring in your compliance folks. The only way you’re going to get good understanding and fast feedback is if they understand what you’re trying to do. And so our approach now is saying, ‘How can we bring not just developers and ops people together, but everybody?’ And I think that will include support folks, and I think that will include business decision-makers, when, with feature flags, they can decide when to turn on features. And that becomes decoupled from the IT infrastructure, so they become part of the conversation in a more powerful way.”
The post Continuous delivery steps into the spotlight appeared first on SD Times.
Tech Developers
No comments