Continuous Integration (CI) is a software development practice that requires members of a team, to frequently integrate their code changes into a central repository (master branch), preferably several times a day.
Each merge is then verified by automatically generating a build, and running automated tests against that build.
By integrating regularly, you can detect errors quickly, as well as locate and fix them easier.
Why is Continuous Integration Needed?
Back in the days, BCI – Before Continuous Integration, developers from a single team might have worked in isolation for a longer period of time, and they merged their code changes only when they finished working on a particular feature or bug fix.
This caused the well-known merge hell (integration hell) or in other words a lot of code conflicts, bugs introduced, lots of time invested into the analysis, as well as frustrated developers and project managers.
All these ingredients made it harder to deliver updates and value to the customers on time.
How does Continuous Integration Work?
Continuous Integration as a software development practice entails two components: automation and cultural.
The cultural component focuses on the principle of frequent integrations of your code changes to the mainline of the central repository, using a version control system such as Git, Mercurial or Subversion.
But applying the cultural component you will drastically lower the frustrations and time wasted merging code, because, in reality, you are merging small changes all the time.
As a matter of fact, you can practice Continuous Integration using only this principle, but with adding the automation component into your CI process you can exploit the full potential of the Continuous Integration principle.
As shown in the picture above, this includes a CI server that will generate builds automatically, run automated tests against those builds and notify (or alert) the team members of the results.
By leveraging the automation component you will immediately be aware of any errors, thus allowing the team to fix them fast and without too much time spent analysing.
There are plenty of CI tools out there that you can choose from, but the most common are: Jenkins, CircleCI, GitHub Actions, Bitbucket Pipelines etc.
Continuous Integration Best Practices and Benefits
Everyone should commit to the mainline daily
By doing frequent commits and integrations, developers let other developers know about the changes they’ve done, so passive communication is being maintained.
Other benefits that come with developers integrating multiple times a day:
- integration hell is drastically reduced
- conflicts are easily resolved as not much has changed in the meantime
- errors are quickly detected
The builds should be automated and fast
Given the fact several integrations will be done daily, automating the CI Pipeline is crucial to improving developer productivity as it leads to less manual work and faster detection of errors and bugs.
Another important aspect of the automated build is optimising its execution speed and make it as fast as possible as this enables faster feedback and leads to more satisfied developers and customers.
Everyone should know what’s happening with the system
Given Continuous Integration is all about communication, a good practice is to inform each team member of the status of the repository.
In other words, whenever a merge is made, thus a build is triggered, each team member should be notified of the merge as well as the results of the build itself.
To notify all team members or stakeholders, use your imagination, though email is the most common channel, but you can leverage SMS, integrate your CI server with communication platforms like Slack, Microsoft Teams, Webex etc.
Test Driven Development
Test Driven Development (TDD) is a software development approach relying on the principle of writing tests before writing the actual code. What TDD offers as a value in general, is improved test coverage and an even better understanding of the system requirements.
But, put those together, Continuous Integration and TDD, and you will get a lot more trust and comfort in the CI Pipelines as every new feature or bug fix will be shipped with even better test coverage.
Test Driven Development also inspires a cultural change into the team and even the whole organisation, by motivating the developers to write even better and more robust test cases.
Pull requests and code review
A big portion of the software development teams nowadays, practice pull request and code review workflow.
A pull request is typically created whenever a developer is ready to merge new code changes into the mainline, making the pull request perfect for triggering the CI Pipeline.
Usually, additional manual approval is required after a successful build, where other developers review the new code, make suggestions and approve or deny the pull request. This final step brings additional value such as knowledge sharing and an additional layer of communication between the team members.
Summary
Building software solutions in a multi-developer team are as complex as it was five, ten or even twenty years ago if you are not using the right tools and exercise the right practices and principles, and Continuous Integration is definitely one of them.
I hope you enjoyed this article and you are not leaving empty-handed.
Feel free to leave a comment. 😀
Follow N47 on Instagram, Twitter, LinkedIn, Facebook for any updates.
