Let us take a walk through on keeping the product delivery on time with Continuous Integration (CI) and Continuous Delivery(CD) pipeline, CI-CD is two different terms which co-relates each other and DevOps is a movement of people term born out of disruption who achieves it with the help of developers and operations guys.
In our context, we can’t speak about Continuous Delivery(CD) without addressing the CI approach. Continuous Integration is a practice with a set of tools to make the delivery fast, reliable and bug-free. In this article I’m not going to explain how to configure the tools, rather I would be explaining the pipeline to achieve the on-time software delivery.
Tools we are gonna discuss in CI model,
- Nexus / s3bucket / any storage medium
The following design pattern represents the interaction of tools each other.
The tagline of CI model is “when a software developer commits a piece of code either it should go to master repo or trash” may be its harsh but true, Let’s start the with Git,
GitHub is a great mechanism of source control, but the ideal case of developers workflow on git would be something like this, work on local master branch or feature branch push it to the remote repo, then send a review request to the team lead on last commit, if a code reviewer miss a bug to pinpoint, it will end up in disaster on hunting bugs in production. To avoid this kind of surprises, Gerrit is inherited into the CI model.
What is Gerrit?
Gerrit is a source control firewall, Gerrit inhibits buggy code to merge into git master branch. It sits on top of the git system by mirroring entire code base. Developers should fetch or push the code through Gerrit. It gives the efficient way to handle review process, more than one reviewer can review with comments and they can give plus one or minus one to the code, (sounds like Facebook 🙂 ). Moreover, it allows setting rules to the codebase that who has to review and merge to the which branch or repository. And most of the open source project use this tool extensively best example is openstack.
I hope you got a reason now to take a look at Gerrit. Okay, what would be the daily life of a developer? it’s more obvious that without CI it will be monotonous and repetitive tasks. Fortunately, Jenkins is being a great tool to handle boring tasks such as deploying the code in a dev environment and handling unit-test cases, code coverage, static code analysis and a lot of other stuff. But we have to understand that this is not a deployment tool, means its an incorrect usage of deploying an application with Jenkins because deployment tool should be idempotent, where Jenkins can’t be compared with it.
Lets assume that build is successfully completed from Jenkins, there should be a common place where the build file, so-called Artifact are stored, for the chaining purpose, here nexus sonatype repository manager or amazon s3 buckets can be used, In later next part of this article, you can understand the purpose of this point.
Continuous Integration Pipeline
- The CI pipeline starts from here, developer clones the Gerrit remote repo then modifies the code base and send it for review.
- Once the review is submitted, Jenkins automatically picks the committed code and create a build, then verifies with unit testing, integration testing, static code analysis, spawning docker contains for testing deployments and a lot of other things could be done. Then sets the verify flag based on the result.
- The verification result would have notified to Gerrit, and mailed to the developer and reviewer who commits the code.
- The last step of pipeline comes to the reviewer who needs to review changes, which has successfully build from Jenkins. And again Gerrit will merge the code to git master only if Jenkins has a verified flag in it.
This complete process keeps the code clean and neat in git master, this could be one of the best methods to apply CI in your environment. Hope you have extracted some useful info out of this post, if not leave your comments I will help you to solve your queries.