CI and Nightly Builds

This is the third blog of a series of posts about the topics Continuous Integration and Continuous Delivery. It explains how important continuous integration is to deliver software in short iterations to the customer with a high quality standard.

In this post I am going to show how to create builds with the TFS 2010 Build Workflow Engine. To ensure code quality and enable continuous delivery, we have usually two different types of builds: CI and Nightly Builds.

CI Builds are executed during the check-in of the developer. There are 3 types of CI builds:

• Continuous Integration Build - Every check-in of the developer is build, but the code is always committed even if the build fails. Even code which is not working correctly will be stored in the productive source control.
• Rolling Builds - Builds a set of check-in's which have been committed since the last build. It has the same disadvantage like normal CI builds and on top it is not all the time clear who created the faulty code.
• Gated Check-in Builds - This type of CI builds just commit the code in the main source control when the build is green and every quality check has been successfully passed. This gives the possibility to ensure certain criteria's and forces the developer to adapt the code if just one of rules in broken.

The task of CI builds is to ensure the code quality. This works great with Gated check-ins because it does not allow to check-in anything which is not according the defined quality criteria.

Nightly Builds are used for integration tests which take a longer time to execute and it would not be feasible to execute them during each check-in process. The Nightly Builds are triggered on a certain time. A good example are Coded UI Tests, which test the user interface by performing clicks and other actions on controls of the screen. A usual practice is to deploy the application every night to the target system and performing completely automated integration and user interface tests.

Overview about a possible development process to prevent broken applications:

• CI Build (with Gated Check-in) on every code change
• Nightly Deployments to Development System
  In order to execute integration and user interface tests it is important to establish a completely automated deployment, which can be executed during the night. After that the automated tests can be executed and instant feedback can be given every morning. It is important that the automated integration and user interface tests cover the main functionality of the application and ensure the health of the application. Additionally, the customer should not test on this system, because it can be broken every morning.
• Weekly Deployments to Staging System
  Only when CI Build, integration and user interface tests have been successfully passed, an automated deployment can be triggered for the staging system. After that the automated tests shall be executed on this system again, in order to ensure the health of the application and prevent configuration errors.
  In that case the customer gets always a stable version on the staging system and can focus on reviewing the implemented requirements.

This process should help to ensure that the customer does not see a broken application and should be much more satisfied about the software quality.