CI/CD Simply Explained!
The concept of CI/CD is very hot in the industry everyone’s talking about this concept, especially if you’re working on the dev-ops, it’s amazing. Every developer should keep an understanding of this interesting concept. If you are interested, this article will help you to have a basic understanding of CI/CD.
Background For CI/CD
What is this so-called CI/CD actually mean? What makes it so interesting? Before understanding this concept, let’s understand why it came. So let’s go back a few years, and let’s talk about the waterfall model. Simply in the waterfall model, a client comes and gives his requirements and ask us to build his project right? And developers keep on building day in day out. Now, in this case, it will take some time for you to make a working project. It may be six months or one year maybe 2 to 3 years. Now, in this case, many issues came across in the development process. Many of them are due to miscommunication. That is something we all know about the waterfall model which is already outdated due to many reasons.
In order to have a smooth flow, you need that continuous feedback that was lacking in the waterfall model. And that’s why we are using a different approach nowadays, which is Agile. With the use of Agile, you give your client a working product every two to three weeks. It's not the entire product but parts of it, most importantly it's a working product. So let’s say if you have 20 features in the full product and you can give one feature in two weeks or three weeks and adding features continuously which is really amazing for both the developers and clients because both the parties will get continuous feedback. This is the first thing you have to understand adding features continuously. And now let’s say, you are working on a project, and in that project, you have certain modules, and you have multiple developers to work on it. And let's say each and every developer assigned to one particular module. And for background purpose, let's say Java is used to develop this particular software and you will write a Java code and you are also responsible for testing. And for testing, you will be using the JUnit(boring stuff are over 🤪). Right now, when you test your class, it is perfectly working so your unit testing is working perfectly. Are we done with it? no right. We have missed another testing called integration testing. When many developers are working in a team the integration of each module should happen and needed to be tested whether they all are working fine as a whole.
Then comes the involvement of the operational teams and QA team. Now your operation teams are responsible to take the project and deploy it on the server. But what about the Integration testing? So for that, we have this automation test thing. Let’s say every Friday the team will deploy by integrating the project, and then there will be an automation test. What if something goes wrong in the automation test. The bug fixing will have to be done at the weekend which doesn't look good at times. So it's a huge problem in the industry where you find bugs when trying to integrate and wait another week or so to deploy after the bug fixes.
Continuous Integration
But it's no more a problem with the concept of CI. So CI stands for Continuous Integration. Imagine that you, integrate your modules very often, let’s say in a day, you will be doing maybe five to six commits which leads to major changes in the output. Every time you think it’s working for you, then you need to test and commit to the shared repository. The advantage would be if you have five developers, all these people will be committed to the repository, and every time you commit, there will be an automation test happening. That means, you write the code, then commit and testing happens behind the scene. So, at the end, or after every commit we’ll be having a production-ready project, which is tested and the team have the confidence of having a working product. So that’s the beauty of CI. In the process of CI, it is not about committing your work at the end of the day or after a week but it's about committing once it's working for you and when the unit tests are working properly, your code is ready to be shared with the repository.
Continuous Delivery
We also have a concept of continuous delivery which comes after CI. Now, In CD we have two parts of CDs, Continuous Delivery and Continuous Deployment. People often mix those two terms which are two different terms. It’s important to understand the difference between delivery and deployment. When you are in the process of continuous integration, you have a perfectly working project which is ready for deployment. If your client says that he wants to see the progress, you can simply show them the working model may be on a demo server. So it will give you confidence and it will also make your client happy which is the most important thing. In addition to that, you can also check the performance of the system. So when you shift your project to your demo environment, it can be called delivery. So of course you will not be deploying it on the production server, but you are keeping it ready for deployment. So at any point, you can think of deploying it. Up to now, we talked about integration in which you’re pushing the code to the shared repository regularly and the rest is handled automatically and delivery is making it available for deployment.
Continuous Deployment
What is continuous deployment then? First thing is to be note is that continuous deployment is a bit scary, because when the moment you commit your code and after the automation test your code will be directly deployed on the production server. If there’s something wrong, you’re gone😶. But it doesn’t happen very often. So you have the code, you’re committed, and first you unit tested it, then there’s automation test, and then it goes to the production server that is continuous deployment. Not every company stick to this process because every company have different requirements, strategies and approaches. Some companies only go for CI, they don’t go even for CD. Some companies go for continuous delivery and some companies go for continuous deployment depending on the requirements and needs. Teams who are working with microservices, believe in continuous deployment, and there are some big companies like Facebook, they adhering to this approach where the code, commit and will be deployed on the server.
So CI/CD is that easy to implement? The answer is no because initially you have to make your team ready for this and secondly you have to get a pipeline so that, everything will happen in a sequence. You will be committing, testing it, and then you’ll be going for deployment which is a huge process that needed to happen in a sequence. So that’s a code pipeline that you have to build. There are a lot of different tools are available for this, we can use Jenkins, which is one of the best tool available.
The Take-Away
A CI/CD pipeline is a sequence of actions that must be done in order to release a new version of the software. Continuous integration/continuous delivery (CI/CD) pipelines are a practice focused on optimizing software delivery using either a DevOps or site reliability engineering (SRE) approach.
