17 March 2013

trigger the feedback process with every change

by mo

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 continuous 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.

  • Launch an EC2 ubuntu instance. A micro instance should do the trick.
  • ssh into your new ubuntu instance.
    • I have an alias in my bash settings. (alias ssh-jenkins-uppercut=’ssh ubuntu@hostname -i ~/.ssh/uppercut.pem’)
  • sudo apt-get install jenkins
    • By default jenkins will run on port 8080. Which probably wont be open to the public given you ec2 port rules.
  • sudo su - jenkins
  • sudo apt-get install nginx
    • you can use nginx to proxy port 80 to your jenkins instance running on port 8080.
    • See these instructions
    • To configure ssl try this post
  • Then you can begin to configure your first job.

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 pursued 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

agile books