Best Practices for Implementing Continuous Delivery

Far from being a single product, the term refers to a culture or “software development discipline, where you build software in such a way that [it] can be released to production at any time,” explains Martin Fowler.

To achieve continuous delivery, a domain has to be created wherein virtually everything must be automated to form a practical implementation of “a highly efficient and productive software development process”. Manual elements have little or no place, as they only lead to bottlenecks and slowing down the all-important delivery.

A holistic solution, continuous development allows changes of all types, “including new features, configuration changes, bug fixes and experiments”, into production and into users’ hands speedily, safely and sustainably. Its successful implementation depends upon software organizations aligning technology, process, people and values.

Read on to find out about:

• The benefits of continuous delivery
• Best practices for implementing continuous delivery

Benefits of continuous delivery

Big companies today are embracing continuous development to treat software development as a strategic capability.

This is hardly an under-the-radar phenomenon: in May 2011, Amazon made changes to production every 11.6 seconds, while Facebook releases to production twice a day. A high number of Google services bear witness to numerous releases each week. Even so, many managers and executives are not convinced about the benefits involved.

Not to be confused with continuous deployment, continuous delivery means you are able to execute frequent deployments, and at a rate that changes from business to business.

Reduced deployment risk

As described by Martin Fowler, continuous delivery involves deploying smaller changes. As margin for error decreases, so the chances of finding a rapid solution to those problems increases. As such, continuous delivery can reduce deployment risk.

Credible completion

If work is deployed into production or a similar environment, it is far more credible as “done” when compared against a developer’s declaration that work is done.

User feedback

Continuous development also enjoys user feedback, as software not being useful is chief among the risks technology faces. As software gets to the user quickly and efficiently, the feedback system should be equally as efficient and valuable.

Functionality

Key to continuous delivery is functionality that delivers customer value. As demonstrated by Microsoft Partner Architect, Dr Ronny Kohavi’s presentation on his work on online controlled experiments (A/B tests) at Amazon. The method created “hundreds of millions of dollars of value for Amazon, and saved similar amounts through reducing the opportunity cost of building features that were not in fact valuable.” Etsy and Netflix are among the many other companies to be using the same practices.

Best practices of continuous delivery

Build binaries one time only

Resist the temptation to construct new code for different environments; binaries should be compiled only once and then stored in a repository to which only your deployment mechanism has access. The mechanism should deploy the one binary to each subsequent environment.

Deployment test in a clone of the production environment

If a testing environment is not identical to that of the production, software may not pass all the tests. A replica of the production environment is very expensive, but this can be circumnavigated if the pre-production environment is built “to be a scalable version of the actual production environment”.

Ensure that your deployment is running smoothly by creating a smoke test to be embedded into the deployment process. A straightforward diagnostics test will help to make sure that everything is in its proper pace. This test will compare a file list of what you should see in your deployment against what finishes up on the server.

Every environment deployed by the same mechanism

The same release process should be used in all environments. Problems will always crop up if a particular feature has to push through one process as it goes to the integration environment, and then through another process into Q&A.

In the event of a breakdown, stop!

Avoid using complex patches, simply discard the process if it’s not working. Rollback any deployments with problem areas and return to source. Having a very small outage window to deploy to your live system may be a top reason why many may say rollback is not an option.

If you have a tiny outage window, “hacking into your live system…will invalidate all your other environments unless you similarly hack all of them well.” Furthermore, the next time the deployment is introduced, the original issue might be allowed back in.

Shared responsibility

While the discipline can be difficult to instill in equal measures throughout the process, responsibility should reach from start to finish, all the way to production. Management and departments should be involved in providing support and encouragement as this culture is assimilated by all parties concerned.

Conclusion

Far from being an overnight remedy, it is important to remember that continuous delivery and its perfecting is a long process. It depends on sustained improvement over days, weeks and months, with teams in charge relentlessly striving for higher, increasingly efficient performance.

The process will bring about huge challenges, as teams adapt to new ways of working, however when these processes are used effectively global organizations of every size stand to benefit.