Reading Time: 4 mins.
What is Continuous Integration?
Continuous Integration, in simple words, is a process of integrating all the development versions of code into a shared repository several times a day. A gradual introduction of the automation tools in the CI process helps in shorter release cycles, faster iterations and subsequently, early detection of bugs, quality code and productive development phase. It works by achieving three major aspects; self-testing builds, automated builds and testing production-like environments.
The code which developed in isolation (by different developers) and when integrated into the shared repository may affect other developer’s code. Further, the integration part itself is an irksome, tedious and risky one to perform and this is where the CI comes to the rescue and helps in simplifying and automating the build and test process of the SDLC. It does this by
- Daily and early commit
- Local testing by the concerned developers
- Updated version control with code changes
- Automated build and testing process
- Fixing of bugs at an early stage
Continuous integration thereby primarily reduces risk and identifies issues earlier in the DevOps practice.
The different stages of Continuous Integration (CI):
Version Management & Branching
It is where the version management tools like Git, Subversion and Mercurial are used. While using a repository, it is equally important to maintain the repository. Eliminate unnecessary and additional third-party files rather the required source code and configuration files. In every version control system, there is a dedicated branching point (master) which is what gets released to the production.
To stay away from bugs, it is better to keep the trunk clean and simple. To implement this, you should not write directly on it but to create a dedicated branch from the master for every development task. Further, it is recommended to adopt a naming system for every differing tasks such as development, features, new release for ease of references.
Pull Request & Code Review
Remember with regard to keeping the repository clean and simple, we’ve created a dedicated branching from the master. It means each of the development work hasn’t been stored in the main branch rather on the dedicated branches. So ultimately the aim of the Pull Request is to merge all those work into a single master branch and thereby, to make the patch open to peer review.
Once the PR (Pull request) is done, an automatic review of the committed code takes place focusing on code quality, documentation standard and security. At the same time, every automated code review comes with some sort of limitations, and it is because of this reason, a final manual code review can be done by peers since the branch is made visible via PR.
Build Source & Status
The source is built and committed with the help of build automation tools. This is where all the build steps are concatenated to get ready for test automation. Though all the build steps are interconnected, they can execute as a separate set. One other perk of this build automation tool is that it keeps track of all the build changes.
Generally, the broken build that happens when one of the automated builds triggers a failure is displayed in red and the passing build is displayed in green colour (often called ‘green build’).
Test Environment & Functional Testing
Next step in the Continuous Integration process is to create a test environment as per the latest version of your software and other using technologies. The necessary prerequisites include; compiling and building of the source code from the repository, integration of third-party tools, configuring the environment settings and thereby, creating a test-ready environment.
Make sure that you have tested every functionality of your software and test also by simulating user traffic. Testing tools like Selenium (for web apps) and Appium (for mobile apps) will do the job. Though it is unreal to perform complete testing, never forget to test the critical aspects of your product. Rely on incremental testing, and it is always better to perform parallel functional testing.
Versioning & Package
At next, the so far carried all the changes are expected to merge into the master branch, either for release or hot-fix. This indicates that once again the committed code must be re-built on the master branch with regard to the merged changes. It is also significant for the Version Control System (VCS) to be tagged and versioned according to the adopted naming conventions. For example, people go with some of the popular naming series such as ‘Placid Pangolin’ from Ubuntu OS and ‘Oreo’ from Android. It is recommended to do the naming for all kinds of major, minor and bugfix versions too.
It is recommended to store the build artifact in the Artifacts Repository Manager as it can be rolled back at the times of emergency. If all the performed testing (both functional and acceptance testings) have successfully done. It is then ready to create a software package for the release/launch of the product as it met all the requirements and specifications.
Role of Continuous Integration in the DevOps process:
Benefits of the Version Control System
The version control system (VCS) helps in tracking the code/build changes (or history) and facilitates reverting to the pre-deployable state when needed. In other words, the version control system will stay updated with regard to the code changes (or new code commit). This is foundational for the successful automation of the Continuous Integration (CI) process. Further, the regular integration of code avoids divergence in different branches.
Continuous testing and early detection of bugs
Performing small and iterative testing avoids troubleshooting the whole chunks of code during the production stage. Continuous testing comes helpful in the early detection of defects (not during the production stage). It follows a series of testing such as Unit testing, Functional testing, Integration testing and Acceptance testing. Further, local testing of the code by the concerning developers will also be performed before it gets integrated into the central repository (or the main codebase). Therefore, early detection of defects means fixing bugs at an early stage which in turn ensures anytime-deployable software.
Security at its edge
Security is one of the important and often-ignored aspects of the SDLC process. Making Continuous Integration an integral part of the SDLC process ensures solid security as CI is all about fostering and maintaining automated (thereby, less error-prone) and defect-less software.
The other benefits of the Continuous Integration include,
- ‘Increased visibility and better communication’
- Faster iterations and reduced risk
- Faster feedback on business decisions
- Avoids manual testing effort
- An automated and structured process
- Earlier prevention of defects
- Reduced debugging, focus on additional features
- Frequent code check-ins, thus, less complicated and modular code
- Uninterrupted and seamless development stage
Conclusion:
The CI being the process within the process of DevOps practice plays a vital part from building the source code until delivering the deployment-ready software package. Nonetheless, in this article, you have seen what makes the Continuous Integration so remarkable; the different stages involved, its benefits and the role it plays in the entire DevOps process. Being the process comprising various phases, it is then followed by Continuous Deployment/Delivery which focuses on the safe deployment of the product.