CI/CD are the two cornerstones of any DevOps operation designed to yield fast and robust software. It is the way of developing software in which you’re able to release updates at any time in a sustainable way. When changing code is routine, development cycles are more frequent, meaningful and faster. From this process, we can make sure that only code that is known to be good becomes part of a software product.
In this blog, we will focus on the following topics
- ??????? Traditional Integration
- ??????? Continuous Integration
- ??????? Continuous Delivery
- ??????? Continuous Deployment
- ??????? Benefits
- ??????? CI/CD Tools
Traditional Integration
Initially the team had no central build server of any kind. Source code may be stored in a central source code repository, but developers do not necessarily commit their changes on a regular basis. Sometime before a release is scheduled, a developer manually integrates the changes, which leads to many issues such as last-minute conflict as many developers may be integrating at the same time or failure of components due to integration.
Some of the drawbacks of Traditional Integration:
1.Developers do not integrate code often which leads to last minute pitfalls.
2.Feedback loop will be slow.
3.Issue cannot be solved easily as there will be many components needs to be fixed.
4.Hard to deliver the Product on time
5.High Cost
In Order to overcome these problems, CI/CD was introduced which includes many advantages both in technical and business perspective.
Continuous Integration
Continuous Integration?is a development practice that requires developers to integrate code into a shared repository several times a day trying to avoid conflicts in the code.
Each Check-in is then verified by an automated build, allowing teams to detect problems early. This allows teams to spend less time on backtracking and more time building new features.
? The concept here is to have?multiple DEVs on a project to keep the main branch of the repository to the most current form of the source code, so each DEV can check out or pull from the latest code to avoid conflicts.
Integration Process:
Developers develop their functionality in their own branch and then push their new branch to a collaborative repository. Automated unit and integration tests run and notify the team about the bugs and other code quality issue. Once the automated tests pass, the developer creates a pull request. A PR allows developers and reviewers to comment directly on the changes the developer submits to the main branch.
Upon completing the review process and merging the new code into the main branch, the feature development and bug-fix cycles continue from the integrated main branch. This often happens several times a day, especially for a large team with everyone working on many small tasks, and it means that everyone is working on the same common code base. Divergence of the code, and the associated problems that can arise from feature developers being out of sync with each other are significantly reduced.
Continuous Delivery
Continuous Delivery is a process where code changes are automatically built, tested, and prepared for a release to production. It is a process where you build your software in such a way that it can be released to production at any time.
The Continuous integrated code commits are further tested for performance and functionality until approved for release. Strong Continuous Integration is required to effectively execute Continuous Delivery. When properly implemented, developers will always have a deployment ready build artifact that has passed through a standardized test process.
This Process starts when the Developer commits the code and ends after the testing is done in the Staging environment, so that the code is ready to deploy into Production. If there are any errors or bugs during the automatic testing, the CI tool automatically will notify the concern developer through a notification such as Email or SMS.
Continuous Delivery usually involves a production like staging area, where changes are manually accepted before releasing it to Production.
The decision to release to production is more of a business decision than a technical decision.
Continuous Deployment
Continuous Deployment is very similar to Continuous Delivery. The Only difference between them is that in Continuous Deployment any code commit that passes all the automation testing phase will be automatically released into the Production Environment.?
Continuous Deployment does not require any manual testing to be done in the staging environment as automation testing will be performed in all the phases of the release.????????????????
Both CDs rely upon real-time infrastructure provisioning and application monitoring tools to discover any problems that were not caught in the testing feedback loops before deployment as there is no human verification.
?????????????????????????????????????????? Diagram illustrating the process involved in 3C’s
Benefits of 3C’s
1.Risk Mitigation
Many developers have the question that “it worked on my local machine but not in the higher instances”. It is because there can be several things that are different between your local environment and where you push to production. Some of the Quality Assurance task such as browser testing can be automated mitigating the risk of a bug making it all the way through to the live site.
2.Faster Time to market
Failures are detected faster and can be repaired fast, leading to increased release rates.
3.Only one source
All the team members must use the same source repository for maintaining their code. It will be clear to see what changes have be made and by whom.
4.Increase in Code Coverage
A CI server checks for the test coverage for each build. Wherever you commit something new without the test classes, the server will throw an error? as there is no sufficient code coverage, so that the developers will work on to increase the coverage in the lower instance, so that there will be no issues while deploying to higher instances regarding to code coverage.
5.Quality: from good to great
CI helps quality assurance (QA) engineers to spend 50% less time of the total project time running nominal tests for integration, looking for bugs and other subtle issues. This allows the QA team to dive deeper into problems, test more scenarios and yield better overall quality and results.
6.Smaller Backlogs
Incorporating CI/CD into your organization’s development process reduces the number of non-critical defects in your backlog. These small defects are detected prior to production and fixed before being released to end-users.
7.Customer Satisfaction
With deployments running in continuous cycles, this will enable you to track the project and provide feedback in real-time, as well as fix shortcomings within your team whenever necessary. With consistent reviews, the new product development will exceed customer’s expectations.
8.Reduced friction between team members
Ensures code worked by several developers across multiple locations are always integrated into a common repository. This avoids the chaos that results from bulky and conflicting code commits.?
Tools to achieve 3C’s
Some of the tools used in Continuous Integration, Delivery and Deployment are,
Ø?Git, SVN, TFS?? – Version Control System
Ø?Jenkins, Bamboo, Team City, Azure DevOps – CI Tool
Ø Junit, NUnit, TestNG – Unit Testing Frameworks
Ø?Ansible, Puppet, Chef – Server Configuration Management Tools
Ø?Kubernetes, Docker – Container Operations
Ø?Cucumber, Calabash – For Integration and Acceptance Tests
Ø?Splunk, AppDynamics – Monitoring Tools
Ø?AWS, Azure – Cloud computing
CONCLUSION
In today’s rapidly changing competitive landscape, business leaders are struggling to release their products quickly to the market because it’s almost impossible to release a quality code without a proper, streamlined process in place.
However, moving to Continuous Integration and Continuous Deployment will change your software development process dramatically and improve the productivity of the organization.
