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.
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.
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.
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.
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.
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.
This story, "Continuous Delivery to Speed Software Delivery (and Reduce Stress)" was originally published by NetworkWorld.