Content area
Full Text
Most software development today is done in teams working on one or more code repositories managed in a version-control system. Individual developers work on the areas of code that require changes and must decide when to commit their changes back into version control.
Sometimes, the code changes are easy and introduce few risks, so the developer can make the edits and commit with a low risk of interfering teammates working on the same codebase.
But what if the team is working on a bigger feature that will require several days, weeks, or even months of development? When is it appropriate to check in these code changes back into version control? Furthermore, what happens when that code is checked in to ensure that the integrated code developed by the team of developers integrates without build errors or other functionality defects?
Why you need continuous integration (CI)
An intuitive approach is to separate out this work into separate version-control branches. Teams decide on whether to use a single feature branch or create multiple ones for each developer.
Although intuitive, it turns out that this way of working is not optimal. Each feature branch has changes that diverge from the main trunk of development. If these feature branches are used for extended periods of time, the integration can be difficult, time-consuming for resolving conflicts, and error-prone.
Larger teams looking to develop and deploy features quickly sought out a new approach where changes are integrated frequently and then use automation to validate the build and functionality. This is now known as continuous integration (CI)