If you want to reduce the time taken by your development organisation to get the system ready for deployment, and your teams are not already doing continuous integration (CI), then it might be something that can help.
Continuous Integration has become a critical component of many organisations development processes. The principle is to combine the changes made by the team regularly, which are then validated by a build process. Feedback is then given to the teams to alert them to issues, so corrective action can be taken.
To get the most out of continuous integration, the process is typically an automated implementation using components such as source control, build servers and test controllers / agents.
Some of the benefits of continuous integration are:
- Faster issue resolution - when teams are alerted to issues quickly they can resolve them in less time because the work is still fresh in their minds.
- More information on the state of the software - allowing those responsible for system release decisions to be more informed.
- Increased quality - defects are found quicker and don’t build up in the system.
- Reduces the risk of there being a long integration periods before a release – because team members integrate little and often.
Here’s a simplified outline of what a continuous integration process looks like:
Possible issues and solutions following growth
Although the benefits listed above can mean improvement to the productivity of a development organisation; that productivity can be reduced by some issues that can arise when a development team grows, or the codebase that is being continually integrated becomes larger.
A typical problem with larger teams is that the frequency of the build being broken increases; with more team members doing more commits / check-ins. This can then have an impact on team members as the master / trunk is broken. One way to address this is by having a method of validating the proposed changes before they are committed to the main source code repository. This could be a manual step (where the team member runs the build on their local computer, or with the introduction of a code review process). There are also methods of automating this, which are often referred to as a gated check-in, or pre commit validation, and support for this is built into some of the 3rd party products that facilitate CI. In some cases it is suitable to have the manual and automated checks.
Additionally, when the codebase of a system grows, the time it takes to build it and run any tests grows also. If this is left unmitigated, it can lead to cripplingly long build times, particularly in situations where a change or patch is required as quickly as possible. This problem is often addressed architecturally. In some cases the easiest way to achieve this is to break the build itself into smaller pieces, which run in a dependent chain. Only the pieces of the system that need to be built, are built. In other cases breaking the system itself down into smaller pieces, which are built separately, can solve the problem.
If you’ve made the decision to initiate a continuous delivery initiative then choosing appropriate technology is an important step. There are many solutions available from 3rd party vendors including Microsoft and JetBrains, as well as Open Source options such as Jenkins and CruiseControl. The models for support are also different, which is also a consideration in the decision making process.
If you already have a continuous integration process set up and running, and are looking at taking things further then have a look at Continuous Delivery.