Programmers and developers know all about “integration hell”. It’s a term that refers to the difficulty of merging several streams of product development at the end of a project. Leaving things late in the day can lead to all sorts of code clashes and going through the work with a fine-tooth comb to get the code up to scratch can be a much bigger job than the original development. One alternative to this approach is continuous integration.
A High-Level Overview
The main principle of continuous integration is that each developer workspace is merged with the main development line multiple times a day. Continuous integration is in essence an offshoot of “eXtreme programming”. In its first iteration the idea was that by using automated testing you could ensure that each development stream was progressing without causing issues to the main body of code. Later iterations incorporated the use of build servers which pick up the latest build and then re-run the unit tests.
In order to use continuous integration you need to start with a code repository (an essential that also allows for strong levels of version control). All objects and artifacts should be held within the repository and each build should be able to be extracted from the repository without the use of additional code or dependencies.
Then continuous integration requires that the build should be automated (and there are plenty of easily available software tools to do just that) and that the build should be self-testing. That means the tests should execute without the need for a manual start from the development team. It’s important that the build is created quickly so that results from testing can be fed back into the development approach rapidly.
It’s recommended that the build is a mirror of your production environment to ensure that your testing environment is a mirror of real-life. Developing testing instances that don’t conform to this principle make continuous integration a waste of time – as there’s a strong chance that the final product will still need to be altered for production.
It’s essential that all developers are working on the same baseline instance each day and that the baseline is committed each day. This reduces the chance of introducing additional creeping errors into the code and allows developers to deal with conflicting code as it arrives. Continuous integration without this simply isn’t possible.
Test results for continuous integration need to be shared with the whole development team. It’s important that there are no arduous steps between programmers and the results – otherwise your development team can’t alter their approach rapidly enough.
There are many benefits to using the continuous integration approach to development:
- There’s an opportunity to quickly wipe faulty code without the need for extensive debugging.
- It minimizes the chance of release date creep thanks to constant checking of functionality throughout the project rather than in a “single hit” at the end of the project.
- It delivers early warnings of failed code and coding conflicts.
- All changes are thoroughly unit tested several times a day.
- There is always a current build maintained which can be used for additional testing, demonstration or even as a release.
- Developers get regular feedback allowing them to address issues while the code is still fresh in their minds – this reduces the amount of time to fix problems.
- Continuous integration forces a modular approach to coding and that keeps complexity to a minimum.
- There are plenty of metrics generated to assist with quality control.
A devops (development and operations) team can help you implement a continuous integration approach for your software development. So you can start reaping the rewards as fast as possible.