Continuous Integration is a leading software development methodology whereby new development is constantly being submitted and tested against the main body of work. The goal being rapid feedback on incremental changes, resulting in lower maintenance costs and higher levels of code stability. The purpose of this article is to begin the process of examining the best practices associated with this particular development method.
There are approximately ten key principles, as outlined below:
- Maintain a code repository
- Automate the build
- Make the build self-testing
- Everyone commits to the baseline every day
- Every commit (to baseline) should be built
- Keep the build fast
- Test in a clone of the production environment
- Make it easy to get the latest deliverables
- Everyone can see the results of the latest build
- Automate deployment
To begin, we will be looking at the first three of the principles.
1) Maintain a code repository
Having a version control system to maintain your code history is pretty par for the course these days. At this point, the issue is not simply having a repository, it’s how that repository is accessed and maintained. CI, as an ideology, is pretty opinionated about this matter. According to CI, there needs to reside a single, central repository, from which all checkouts and testing is done and to which all commits are pushed. The rationale for this is maintaining one single source of truth at all times and avoiding instances where a change works in a development environment but not production. This being the case, branching is discouraged – at least in the sense that CI does not want you to maintain parallel version of your code.
2) Automate the Build
In a CI system, builds should happen automatically when a developer submits their code, and as much as possible, should be free of manual steps. This is a prerequisite for points 3, 5, 6, and 10. Not only is this point important for the speed of the build process (which is arguably the reason for doing CI in the first place), but it imposes a standard of consistency and repeatability that is vitally important for ensuring quality and tracking progress.
3) Make the Build Self-Testing
If a build requires manual testing, then the build will be slow and the chances of errors sneaking through will also increase. Ideally, CI would prefer that all tests are run with every build, but the reality of the situation is that this is frequently not practical. In many cases it makes more sense to run the tests pertinent to the affected modules, aggregate a set of changes and then run that aggregate set through the full complement of testing. Fewer tests means a faster test execution time and quicker feedback to the developer while submitting batches of aggregate changes conserves organizational resources.
David Hubbell
Software Engineer
SPK and Associates
Next Steps:
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
