Five vital steps to Continuous Integration
In our effort to provide competitive products and services we face an increasing rate of requirement change. The answer to this dilemma is to adopt a development strategy where you at all times have a release candidate ready.
Continuous integration implies that you automate the process of handling code that a developer has committed (or is about to commit) to a repository. The code is automatically checked for correctness by automatically checking adherence to coding rules, successful compilation, unit, integration and acceptance tests. We can employ different strategies when to allow the code to be committed to the repository. A strict scheme, that will result in you always having a releasable software, is to only allow code to be committed when all test are successful. Using continuous integration allows you to automaticaly deploy your software (continuous deployment) or to make customer deliveries after some manual interaction (continuous delivery). This has the potential to solve our dilemma with rapidly changing requirements!
But how to get started? What steps should I take? In our experience, and we do set up continuous integration for small teams up to teams with over 2000 developers, there are five vital steps to consider:
- Maintain a code repository
Use a revision control system for the project's source code. All artefacts required to build the project should be placed in the repository. - Automate the build
This shall include automating the integration, which often includes deployment into a production-like environment. In many cases, the build script not only compiles binaries, but also generates documentation, website pages, statistics and distribution media. - Make the build self-testing
When the code is built, all tests should run to confirm that it behaves as expected. The tests shall include production-like environments. Also make the results, including the latest deliverables, of the latest bild/test available to all developers and stakeholders. - Make the build/self-test fast
The build and tests need to complete rapidly, so that if there is a problem developers quickly get feedback. - All changes are committed and built
By committing regularly, developers reduce the number of conflicting changes. Early, small conflicts in an area of the system cause team members to communicate about the change they are making. Checking in a several day's worth of work runs the risk of conflicting with other features and can be difficult to resolve.
Having completed these five steps you are confident that your software is ready to continuously be delivered or maybe even automatically deployed to your customers!
