Continuous Integration is a practice, not a tool. Implementing a successful CI practice within an organization requires discipline, particularly when your development environment contains a significant amount of complexity. Much of what we talk about in our CI series is establishing discipline and best practices that become engrained in our processes. Best practices are methods or techniques that consistently bring superior results. Best practices evolve over time as new technology and techniques are introduced or improvements discovered.
Here are 10 best practices for continuous integration that will be especially helpful for those new to CI or wanting to improve their current processes.
Ten Best Practices for Continuous Integration
- Manage Source Code, Using a Version Control Product
The best way to manage source code is to use a version control product, which will provide a complete audit trail and history of the code. It’s also the place where the build server can monitor the code to determine any changes.
- Version All Test Scripts and Configuration Files
Test groups and configuration files are similar to source code in that they change frequently and need to be audited and traced. They should be kept in the version control system. That way, teams can revert back anytime to previous versions of the code for comparison.
- Enable Triggering of Builds from the Command Line
Teams should streamline the build process so that it uses common, standard tools. For example in the Java world standards to use would be Maven, ANT, NANT. To enable triggering of builds from the command line, teams should also standardize on a build script/tool and incorporate unit testing into the build process.
- Commit Frequently (at least once a day) as a Developer
Developers should commit frequently – at least once per day – several times a day is recommended. By doing so, developers will know the real time state and health of the software
- Integrate Frequently; Build the Mainline on the Integration Server
Developers should integrate code changes frequently, so that integration doesn’t become such a hard process. Once teams begin doing this, they should have the continuous integration server building that main line.
- Enable Fast Builds (Typically <10 minutes)
Builds should be fast. Anything beyond 10 minutes becomes a dysfunction in the process, because people won’t commit as frequently. Large builds can be broken into multiple jobs and executed in parallel.
- Test Using a Replica of Production
Testing should be done in a production-like environment. The build server should be built to the same standards as production. Not necessarily in terms of being locked down and tightly regulated, but it needs to have the same version of operating system, patches, libraries, and so forth. That way, when the binary goes into production, there won’t be dependency issues.
- Use a Central Binary Repository
A central artifact binary repository helps to manage and govern the binary artifacts and associated metadata. It also helps to enable end to end traceability by making it easier to associate binaries, builds and versions of source code.
- Make it Easy to Obtain Build and Test Results
Build and test results should be easy to obtain since they are key to ensuring good quality. Developers should be able to easily see these results – especially when the build breaks. Developers should be notified as soon as possible as to why it broke, so that they can fix it as quickly as possible.
- Automate Deployment
Automating deployment helps to reduce waste. Many continuous integration servers already have plugins for automating deployment to various web application servers like TomCat, JBoss, and WebSphere.
In the spirit of community and establishing a forum for us to share, we’d like to hear from you. What are some best practices that work for you and your organization?
Subscribe now to receive automated updates.