A good software development process avoids going off on fruitless tangents. In 2010, Jez Humble and David Farley presented a way to stay on track in a book called Continuous Delivery: Reliable Software Releases through Build, Test and Deployment Automation.

Continuous delivery builds on the idea that developers should create software in small increments and takes it a step further. Its standard is "ensuring our code is always in a deployable state." It aims to be able to issue a new release at any time, so that business considerations rather than stubborn bugs determine the release time.

The bigger the change from one version to the next, the harder it is to figure out the cause of any problems in an application. Making small changes and testing them thoroughly is at the heart of continuous delivery.

Its main technique is the deployment pipeline. When developers make any changes, they immediately run a set of automated tests. If they create code to do new things, they create new tests along with the code, not afterward. Each cycle tests the entire body of code, not just the changes, to make sure that work on one place doesn''t break something that seemed unrelated.

Manual testing is also necessary, since a real live person is necessary to try things that the developer didn''t think of. Keeping manual testing from breaking the continuity requires close and constant communication between developers and testers. In the traditional model, developers tinker with code for a while, then they create an alpha version for in-house testing, followed by a beta version for trusted users. With continuous integration, testers get changes on a regular basis and give quick feedback. This can reduce the traditional alternation between having nothing to do and being under deadline pressure.

What''s the right development strategy for your project? Please contact us to learn more.