Why continuous delivery is a must practice for software development teams?

My good friend, @elad_roz said something interesting about YAML. He said that YAML is better format then JSON, not because it's more simple, but because it forces you to work with right text indentation due to it's nature of figuring out the data structure according to the text indentation. We all know that source code / data file which is correctly and uniformly indented, is much simpler to understand and maintain.

Same principal goes for software development. We know that in the new challenging world of increasing demands from the software quality, complexity and the speed software is delivered, our only saviour is automation. If we don't automate things like build, deployment, integration tests, regression tests and functional tests, we don't have a chance to deliver valuable software to our customers.

The point in continuous delivery practice, is that it enforces the development team, the QA team and the Managers, to invest heavily in automation. If each code change, is a potential production version, to keep up the speed, you have to automate everything. There is no time for manual regression testing, there is no time to write deployment manuals and there is no time to execute any of the steps needed to promote a software change to production, manually.

The pace and the complexity of the business requirements from software development teams is constantly increasing. The only way teams can continue to successfully deliver the expectation, is by increasing the pace of the development by embracing the latest technologies and agile practices. Continuous delivery is a practice which will help you to understand the benefits of automation because it's not always clear to development teams and managers what is the benefit, in the first look. The reason for the unclarity is usually due to the fact that automation is hard to start with. If you don't have a single automatic functional test, you will have to invest a lot of resources, just to get started. And if you already started, each new feature or a bug fix you deliver, has to come with automation. This, from one point of view, extends the time to production floor of the feature, but from a different point of view, pays off in a later stage, where you discover problems in a very early stage of the development process, and don't waste valuable time on manual testing and version promotions. Another reason why this pays off greatly is the human nature. People are not very good at doing the same steps over and over again. They eventually get bored, and then the quality of execution will suffer.Automation saves your team from this boredom, and saves a LOT of time.

As the continuous delivery starts to be very trendy, some of the teams might start working with this paradigm, without fully understanding the practice. This might happen due to different reasons starting from leadership enforcing the teams to work in this manner, but not providing the teams time and resources to learn and adapt, or even a business pressure to deliver, where the management decides to cut in the automation, because it's the easiest place to cut the development times. Teams with this problem, will fail to deliver quality and speed. It's might not be seen right away, but only after some iterations of the development / production cycle.

Conclusion: if you decided to go the wonderful path of continuous delivery, first you must understand the philosophy, then you must be ready to invest heavily in the infrastructures of such a practice, and only then you will be able to enjoy the major benefits.