Continuous Integration and Enterprise Build Automation


How often have you or one of your teammates checked the source code into the code library which then instantly triggered an automated build?  How many times did this instant build succeed? Do you have an automated build and release system that ensures your software is built in the same way each and every time? Are deployments to staging environments entirely automated and executed with a single click? While reviewing a defect in a production release, are you able to backtrack through the source code changes and identify the root cause of failure? If the last good checkin happened a few days ago, identification of this root cause of failure would become even more difficult. Seasoned CM practitioners advise that you perform a daily build to avoid such integration issues. What an irony it is that only a few projects take advantage of this simple, yet powerful technique known as Continuous Integration (CI).

Read on if you would like to explore the use of continuous integration, build and automated deployment. An automated build framework not only helps in solving integration issues early, but also assists by building and deploying the complex products quickly and further helps in ensuring that the build processes are transparent, auditable and repeatable.

Continuous Integration - A step towards quality
In the words of Martin Fowler, Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

While a large number of teams claim that they have continuous integration framework in place but in reality most of them do not. Many teams do not write unit tests or they do not have automated deployment mechanism in place. Eventually, they end up doing just continuous compilation which is of little help. Most of these teams do have build automation tools, but they do not use these tools to their real potential. It is like having good paint and brush tools, but not knowing how to draw a good picture.

Types of Builds in Continuous integration
How does one get started with continuous integration? There is no fixed start-to-finish recipe, but as a first step, it would be good to setup a single code library so that whole system can be built with a single command. The next step would be the identification of build types which should be configured. Pre-release builds (hourly/nightly) help developers to improve the quality of the source code and release builds help in automating the release process. A typical build cycle should have the following four types of automated builds.

Hourly build , configured to check the sanity of source code, should at a minimum compile the source code and execute the unit test cases. Hourly builds are a good friend of developers and provide them immediate feedback if something is broken. Some Teams prefer to configure automated code reviews within the hourly build plan as well.

Nightly build (or daily build) is another automated build which takes place when no one is in the office. Nightly builds are configured to test the software in a test suite. Test results from nightly builds provide developers the feedback on how their test suite is progressing. The following activities can be part of a nightly build

  • Compilation & execution of unit tests
  • Automated code review
  • Creation of code coverage report
  • Creation of design quality matrix for each source code package, dependency analysis and cyclomatic complexity
  • HTML-based cross reference of entire source code
  • Automated deployment in a staging environment
  • Execution of automated functional and regression test cases
  • Notification to stakeholders about build outcome by email and/or on central build dashboard

Release build is configured to make a release to QA. It is always recommended to automate the steps of a release build. The standard build steps would include:

  • Tagging the source code
  • Compilation and creation of the build package
  • Creation of installers
  • Moving deliverables to release area
  • Creation of release notes and publishing the same on the project dashboard
  • Automated deployment in testing environment
  • Execution of automated functional, regression, performance and acceptance test cases and creation of test report
  • Publishing the build artifacts
  • Notification to stakeholders about build outcome by email and on central build dashboard

Promotion Build is configured to move the tested build artifact from one level to another (e.g. from QA to Release). The steps would usually include using

About the author

CMCrossroads is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!