Basic Understanding of CI & CD

There is a lot fuss about the term called CI/CD in DevOps world, looks like people have mixed both thing: one is as a conceptual part and the other part where you talk about the tools which are used for this process itself.

There is a reason why I am saying this because I have had a lot of discussion with people around and while having discussion, I figured it out that they always start the discussion with Jenkins and Ansible while explaining fundamental of CI and CD which is really not what the answer is !!

Many would argue here that Ansible is not a deployment tool instead it’s a software configuration management tool. !! Totally Agreed here but it has kind been transformed for CD as well lately.

Let me put my understanding of CI and CD as conceptual and CI and CD being used practically.

Continuous Integration !!

Continuous integration is about working with version control system, automated code building and automated testing. The core concept here is that changes in the code are continuously integrated and tested properly.

Let’s explore this with a simple example here to get the better understanding.

Suppose you are a developer and working with your fellow team members on a particular project where you have to deliver a feature demanded by Management team as soon as possible.

So you will probably follow the same process mentioned below:

• Pulling a copy of the existing code on your machine from your repository , could be Git or SVN.
• Will modify your code with feature changes.
• Will most probably build the code and test the changes with test cases before committing the code back to feature branch.

If everything works fine in your local then you tend to commit the code to your feature branch and continuous integration process ( Jenkins or other CI tool ) will kick in to have the automated build and test cases.

If you were thinking that this was all which included in CI then you are probably wrong here.

This is where you run into the problem because you find out that you are not alone in you team and this is highly possible that your team member also may have been working on the same time on the same feature. And if they committed the changes at the same when you were making changes to your code in your local then there is possibility of having a conflict, and if that’s case then the test cases which run when you push the code might fail, which again makes you repeat your process from the scratch.

Once it’s working with latest code, you can commit your changes to the feature branch and from there, If the automated build and tests work as expected, the stable branch is updated and you move on. If not, you try to figure out why and it goes on until you fix all the conflicts.

Things to learn from here:

Automated builds and tests are part of CI phase and issues are caught at early stage of the development

Version control and CI process are integrated to trigger the builds and tests for each and every commit made by developer

Committing multiple time of the day as you are changing your code is the important part of continuous integration process

Continuous Delivery !!

Once you get the understanding of CI, continuous delivery becomes much more easy to work with. This is the next possible step where after having the build tests passed the code is automatically deployed to Staging and Dev environments respectively .

Then if possible we can have integration tests and other functional tests as well to ensure that the code would behave in an expected way in production environment. Not all the companies have all the functional testing in automated fashion that’s why manual testing comes into the picture and your QA team will do the sanity of the newly deployed code.

once all the tests in this stage are passed, then the code can be deployed on production manually of course after it is approved so the important thing to remember is that we do have manual intervention in continuous delivery phase.

Things to learn from here:

Automated integration, functional and acceptance tests are part of the continuous delivery phase, manual testing can also be here.

Rapid and continuous feedback from the consumer ( QA and UAT team ) of the product

Production ready code but isn’t deployed on the production in continuous delivery phase

Continuous Deployment !!

You must be thinking where this phase will fit in ???

That’s really a confusing part here because you may have heard lots of people referring CD as “Continuous Delivery” or “Continuous Deployment” and at the same time mixing both the definition together.

But this isn’t as difficult as it looks like, it’s actually very simple

Continuous deployment is exactly what continuous delivery is, except one thing where the builds which pass through testing are automatically gets deployed in the production. This is different from Continuous delivery where we needed manual intervention/approval before deploying the code to the production.

Final Thoughts !

Understanding the process of continuous integration and continuous delivery/deployment is very important part of DevOps which enables you to focus more on the automation of all aspects of software life cycle and makes life easier of fellow team members.

Till the next time — Happy learning :)