This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
Discussions about continuous delivery to facilitate the rapid and reliable delivery of software have been showing up all over the place, and with good reason. Continuous delivery brings together automated testing, continuous integration and automated deployment, which enable businesses to deliver functionality to customers more frequently and with fewer errors. Some of the most successful organizations in the world use these practices to deploy hundreds of small changes in their software every day, eschewing infrequent, large releases.
With frequent and rapid releases, continuous delivery can reduce stress throughout an organization, even as the pace of change dramatically increases. But, when you stop developing towards single large changes and start making many small changes, you have to alter the way you work. And these new ways of working end up reducing your stress levels.
+ ALSO ON NETWORK WORLD 5 things you need to know about continuous delivery software development +
I’ll admit that this may not sound likely. If making a single larger change is painful, it would seem to follow that repeatedly making many small changes that build up to that single larger change would be even more difficult. However, the problem with the traditional method is that you create a lot of risk when you do a large change in a single step because, if anything goes wrong, you're not sure which part is responsible for any problems you see. You might be overwhelmed by testing a big code drop and be unable to sustain the level of concentration required to test all of the expected changes by hand, or even understand the full impact of the change.
There are five main reasons that continuous delivery reduces the stress levels throughout an organization. Seeing how continuous delivery achieves some of these might be a bit surprising.
- When you take repetitive, tedious and boring tasks and automate them, it frees up people to work on the truly interesting problems. In fact, the first “truly interesting” problem you are likely to face is how to automate some of your tasks in the first place!
Automation is key to the success of continuous delivery. Any routine step that is currently done by a person needs to be encapsulated into a repeatable process that doesn't depend on an individual’s memory, organizational folklore or hand-written instructions. You should be able to do a system build—complete with unit tests, integration tests and automated user tests—from a single command.
Increased automation increases consistency and speed of work. Consistency removes many avenues for mistakes and reduces the overall rate of mistakes. That's in contrast to a traditional environment in which things aren’t automated and “human error” is an all too common explanation for mistakes. When people are bored and doing the same thing again and again, the probability of mistakes goes up. Mistakes – especially unnecessary mistakes – are stressful.
- By increasing automation, you make it possible to run many more tests in much less time and cover more of the system. Continuous delivery relies on automated testing because it’s the only way to achieve this level of turnaround and quick feedback.
As soon as you make a change, the automated tests can tell whether something has gone wrong. And if it has, it’s easy to trace it back to the change you just made. In other words, if I make a change and something is no longer working as we expected, it pretty much has to be my change.
- When you make changes in smaller units, you can be more confident that you understand the impact of a change. If you don't understand completely what it does, you're at least protected by the rest of the tests in the larger system. Any way you slice it, smaller changes equate to less uncertainty about the impacts and let you relax.
- When you do continuous delivery, your new code is tested not just at the unit level but also in the context of the whole system. This tells you much earlier not only whether the component works, but also whether all of the components together produce a working system.
What happens when integration testing fails? It’s better to know that sooner than later and adjust accordingly to make sure the system as a whole works together. By bringing this testing as close to the front of the process as you can, it reduces the amount of mystery about how it will all work together later. By reducing mystery about how everything fits together, you substantially reduce stress.
Contrast that with making changes in a big batch and waiting until the end to put it all together. This approach risks creating components that work perfectly according to their specifications, but don’t combine together to make a full system that works according to its specification. Figuring out that this is the case can be a long, painful, demanding process as many different groups, each responsible for different components, try to decipher which part isn’t working correctly. With continuous delivery, you tackle integration problems sooner, which mean less stress.
- In my experience, the handoff to an operations team is one of the most arduous things we ever do in software deployment. Two groups that too rarely talk to each other now have to work together. The development group has been making assumptions, which are often unverified, about how the production system works. The operations team has been left out of the loop about what changes to expect in the behavior of the system.
By deploying more often, you reduce the number of untested assumptions, and you’ll also now have much more regular communication between the two groups to figure out what’s going on, what’s working, and what’s not. In other words, with continuous delivery, you talk to each other more often and you build up rapport. As rapport grows, people start talking. Both groups learn things about each other and begin to work together.
Contrast that with saying, “Here are the 50 changes I talked to you about three months ago. Make them run in production.”
Who knows if both groups understand the impact of those changes?
There isn’t any exchange of understanding and no acknowledgment of uncertainty, just a command to comply. With frequent, smaller changes, you talk more often—making mistakes from misunderstandings less common.
A lot of people think of continuous delivery as living on the edge, but as you’ve seen from these five points, it has just the opposite effect. Instead of increasing stress, continuous delivery lets everyone sleep better at night, meaning the end of all-nighters at the end of a big release cycle. Deployment, which was really taxing in the past, becomes routine and is no longer the taxing process it once was.