I am currently reading Continuous Delivery. In the first chapter, the book suggests that each change to executable code, configuration, host environment and data should trigger the feedback process. This is because a change in any of the components of the system can change the behaviour of the application.

Every time a change is made to the source code, the resulting binary must be built and tested. In order to gain control over this process, building and testing the binary should be automated. The practice of building and testing your application on every check-in is known as continous integration - Continuous Delivery

There are many different offerings out there for getting a continuous integration (CI) box in place. My first experience dabbling with CI was with CruiseControl.NET, later moving to Team City. Most recently, we have been using Jenkins.

It’s super simple to get a Jenkins server up and running.

On teams using continuous integration, there is some basic etiquette to abide by. * Check in often. * Don’t break the build. * Fix broken builds. * Don’t check in code over a broken build.

Watch this for a great lesson on Continuous Integration Etiquette.

Investing in build and deployment automation can increase quality, increase confidence in the project, decrease regressions and decrease the amount of necessary manual testing.

In an environment where build and deployment automation is aggressively pursuied along with comprehensive automated testing, there is no need to spend time and money on lengthy and manually intensive testing at the end of the project. At this stage the quality of the application is usually significantly higher, so manual testing is only an affirmation of the functional completeness. - Continuous Delivery

The traditional development processes typically put testing (QA) near the end of the project life cycle. Continuous delivery suggests that delaying testing until the end can increase the cost of fixing defects.

delaying testing until after the development process is, in our experience, a sure-fire way to decrease the quality of your application. Defects are best discovered and fixed at the point where they are introduced. When they are discovered later, they are always more expensive to fix. The developers have forgotten what they were doing at the time when they introduced the defect, and the functionality may have changed in the meantime. - Continuous Delivery

comments powered by Disqus