“If something is hard, do it often.”
1. Introduction
Integration can often be a long and unpredictable process. Continuous integration (CI) is an approach that reduces the risk and attempts to treat rare and complex integrations as non-events.
2. What is Continuous Integration?
On a very basic level, Continuous integration (CI) is the software development practice where members of a team regularly integrate their code changes into a shared virtual source code repository. Usually each member commits at least once if not several times a day.
A source-code repository (or source code management system) is a central file storage location typically hosted on the web where teams maintain and integrate (commit) their local source code. Usually developers work on separate branches, these are used to store different versions of the code prior to their consolidation with the trunk. The trunk contains the most current and up-to-date version of code, unifying all of the branches. Source code repositories are hosted either publicly or privately. Popular free options include Github [1] and Gitlab [2].
Teams link their source code respository with a CI tool Jenkins, Travis or TeamCity. Some code repositories servers like Gitlab also offer CI features.
Prior to every commit, the team member should follow the rules set by the lead, such as pulling (integrating locally) updates from the repository, addressing conflicts, writing new tests and running tests on their local working copy.
It is their responsibility to fix any failures and ensure that the working (local) copy is properly synchronized with the mainline. Only then can they finally commit into the mainline and update the team's virtual repository with their new code.
The commit will then signal to the CI tool to run an integration build (sometimes referred to as a pipeline) on the files living on the server. These steps typically (but not limited to) include:
Running a build -ensure the new code is compilable
Merge branches -ingrate your code with the trunk
Execute tests - to help identify if anything was broken by the committed change, any regressions and build errors should be resolved immediately.
Deploy code - republish the application with the updated code
Running tests virtually will catch errors in case proper practice was not followed earlier. Should the build fail, the error is detected rapidly and the team's most important task is to fix it and get the build working properly again. The idea is to maintain a functional and up-to-date build of the system in development.
Continuous Integration attempts to be "self-testing" and assumes a high degree of tests. Often these use a version of the popular XUnit testing frameworks.
3. What are the advantages of Continuous Integration?
• Breaks hard tasks down
CI is advocated by proponents of the agile software development methodology. One type of agile is Extreme Programming (XP), a core principle from which is “if something is hard, do it often”. Committing frequently prioritises small changes over large changes. It encourages developers to break down their work into small chunks doable over a few hours. This provides a sense of progress and boost to general team morale. You may not think you can accomplish something meaningful in just a few hours, but I’ve found the opposite to be true - providing however - a positive mindset is exhibited from each team player. This culture should of course be fostered by the team lead.
A software development methodology is a method of project management. Agile attempts to break the mould of traditional engineering practices and is characterised by the division of tasks achievable over short time frames. This helps to permit Agile's other core attribute of constant reassessment and adaptation of the software as it develops and not solely following delivery.
• Fast feedback loop
What you don’t know really can hurt you and this is particularly true in software development. Quick feedback on the quality and impact of any changes you’ve made will save significant time down the line when you’re trying to figure out which change caused a calamitous break! The sanity checks enforced by Continuous Integration provide a quick answer to everyone’s fear, “did I break something?” sparing you from the vengeful wrath of your colleagues.
• Reduce context switch
Good CI insists on daily code integrations at a very minimum, and encourages multiple daily commits. Some teams configure their pipelines to merge automatically. Since merging with the main branch is happening in very short intervals, the few merge conflicts that do crop up (if they do!), are effortless resolved especially since people are ‘in context’ with their recently written code.
• Quick time to market
A software is composed of many different components. Automatic builds and merging make each component go “click!” without much effort or friction helps the team to progress with little need to backtrack extensively.
Manual deployment is time consuming and often requires experts knowledgeable in the target domain. Since increasingly software is deployed on infrastructure-as-a-service (IaaS), automating deployments with CI also has become essential part of cloud computing.
Infrastructure as a service (IaaS) is a form of cloud computing that provides virtualized computing resources over the internet such as operative systems, storage and data center space. For example, this blog is hosted on a virtual linux for which I pay a monthly fee.
Often, you will find this step distinctive referred to as continuous deployment (CD).
CI removes some of barriers to regular functional delivery to the client for live feedback and quick necessary adjustments, boosting your agile credentials.
The first principle of agile manifesto is, “Satisfy the customer through early and continuous delivery of valuable software”. (https://agilemanifesto.org/principles.html)
Accelerated time to market and improved handling of their feedback help to better meet client expectations. I’ve found that this improved satisfaction overall will motivate companies to invest more in CI and CD.
4. What are the disadvantages of Continuous Integration?
• Requires team discipline
CI is only as effective as the team’s ability to use it.
One ailment that undisciplined teams suffer is ostrich syndrome. Ostrich syndrome refers to an affliction some people exhibit when they are confronted by a difficult or controversial situation, whether in their personal or professional life.
Rather than confront it head on as they should, they refuse to acknowledge it and as the ostrich does, metaphorically bury their head in the sand hoping the danger will go away!
In CI, a regimented team must systematically deal with issues as soon as they arise undeterred by the sensation that doing so will reduce their ability to hit those ever looming deadlines.
Dont let "tool = practice" , let tool == practice!
Teams may end up treating CI tools as simple commit verification tools without manually or automatically merging their branches until just before their release date. These teams are therefore unlikely to benefit from early dependency resolutions and regression avoidance because their integration which they call “merging” happens only once towards the end of the release.
• Slower builds
Dutifully adding unit tests (typically for every new functionality!) encourages, can increase build times over time which you should monitor to prevent creep and identify when it makes sense to use test parallelization.
Some teams set their pipeline to run automatically overnight to execute tests and merging in order to resolve conflicts first thing next morning.
Parallel testing is where instead of running tests sequentially, you split the load between multiple environments, typically virtual machines. If your project has a large number of tests, this can save teams time and money.
5. CI tools
• GitLab
• Jenkins
• Travis
• TeamCity
6. Tips
Blameless CI
Vivek Ganesan (2017) [1] in his book, Blameless Continuous Integrations argues that CI should embrace the “build breakers” and promote a teamculture that doesn’t point fingers or judge other team mates. This, he argues, removes some of the fear of screwing up when churning out code and committing frequently.
7. Conclusion / TLDR
• Integrate your changes every day • Write the tests for everything • Automate testing and branch merges with a CI tool • Fix faults as soon as possible • Keep the main build functional • Foster a proactive team spirit
References
[1] Blameless Continuous Integration: A Small Step Towards Psychological Safety of Agile Teams, Vivek Ganesan 2017
About the Author
