Continuous integration is a practice that consists of two main components:
- Merging source code changes on a frequent basis
- Building and testing the changes in an automated process
The main focus of continuous integration is frequency. By merging, testing, and building rapidly, we can prevent a lot of problems that could occur with many developers working on a single piece of software. Let’s take a closer look at how.
No more long-lived branches
One of Anita’s problems was that she used large branches which she worked on for a long time. As other team members start contributing to the main branch, her branch will start to fall behind.
By switching to continuous integration practices, Anita now merges smaller changes more frequently. This follows the branching strategy of trunk-based development rather than feature branch development. Here’s the difference:
Feature branch development — Merging in long-lived branches containing entire new features
Trunk-based development — Merging in small changes frequently into the main branch (called the trunk)
Take a look at this diagram showing how each branching strategy performs differently.
Hint: You can expand this “Learn” panel to get a better look
Less merge conflicts
Rapidly merging smaller changes means that there is less of a risk for merge conflicts. If any are found, they can be addressed quickly and require fewer changes due to the small size.
Each new change automatically triggers building the application in an integration environment (sometimes referred to as a “CI server”). Through continuous testing, tests are executed immediately as changes are introduced. As a result, bugs are caught early on in the process.
Take a look at the provided GIF. Notice how new code is frequently built, tested, and merged.
Can you recall which branching strategy is compatible with continuous integration practices?
See the answer!
Trunk-based development is compatible with continuous integration practices. This is because it uses frequent merges which is a requirement for continuous integration.
After continuous integration, the app has been built and tested with automated unit and integration tests. Next, the application is moved into intermediary environments to be tested again, this time to prepare the application for production.