Introduction To CI/CD
Introduction To CI/CD
fundamentals DevOps.
DevOps Stages
What is CI CD Pipeline?
Testing Phase:
Once the build phase is over, then you move on to the testing phase.
In this phase, we have various kinds of testing, one of them is the unit
test (where you test the chunk/unit of software or for its sanity test).
Deploy Phase:
When the test is completed, you move on to the deploy phase, where
you deploy it into a staging or a test server. Here, you can view the code
or you can view the app in a simulator.
Deploy to Production:
Meanwhile in every step, if there is some error, you can shoot a mail
back to the development team so that they can fix them. Then they will
push it into the version control system and goes back into the pipeline.
Once again if there is any error reported during testing, again the
feedback goes to the dev team where they fix it and the process re-
iterates if required.
Measure+Validate:
So, this lifecycle continues until we get a code or a product which can
be deployed in the production server where we measure and validate
the code.
CI/CD
The primary goal of any software project is to earn money through the
automation of the business process. The quicker you can release the
new versions to the customers, the better it is for your company. But
how to implement the release process in a fast way? Well, you could do
it manually but today we’re going to be discussing the automation of a
product releases and development process itself.
CI
1. How can we know that the code that goes to the master branch
compiles?
2. We want the developers to write tests for the code. How can
we verify that the test coverage is not decreasing?
3. All team members should format the code with the specified
code style. How can we check the possible violations?
Basic CI
The process guarantees that any code that goes to the master branch
does not break the further builds.
Let’s make the task more complicated. Suppose that we want to set the
minimum test coverage bar. So, at any moment, the coverage of
the master branch should not be lower than 50%. The Jacoco plugin can
solve the problem easily. You just need to configure it in the way to fail
the build, if the test coverage value is less than the accepted one.
Imagine that you’re working on a product that is five years old. Since
its first commit, there has been no test coverage checking. Developers
added tests randomly without any discipline. But one day you decided
to increase the number of tests. You tune the Jacoco plugin so the
minimum bar equals 60%. After a while, a developer opens a new Pull
Request. Then they suddenly realise that the test coverage is only 30%.
So, to close the task successfully it's obligatory to cover at least 30% of
the product code. As you may guess, it's almost an unresolvable issue
for the five years old project.
What if we validated only the upcoming code changes but not the
whole product? If a developer changed 200 lines within the Pull
Request, they would need to cover at least 120 of them (if the test
coverage bar equals 60%). But it wouldn't be necessary to walk through
the tons of modules that aren't part of the task. This can solve the
issue. How can we apply it to the project? Thankfully, there is a
solution.
CI with test coverage checking
CD
Let’s put some changes to the CI schema. That’s how the CI/CD
process may look like in a real project.
CI/CD process
Firstly, the CI server is named as CI/CD server now. The thing is that
frequently both CI and CD jobs are executed with the same task
manager. So, we’re looking at this approach.
Though that’s not the rule. For example, one can delegate CI jobs
to GitLab CI and CD jobs to Jenkins.
The right part of the schema represents CI. We have discussed it
earlier. The left one pictures CD. The CD job builds the project (or
reuses the artefacts generated during the CI stage) and deploys it to the
end server.
After the deployment stage completion e-mails are usually sent. For
instance, the CD server can notify subscribers of the succeeded or
failed deployment.
4. Combined option.
The first point sets the process so the CI and CD jobs always run
sequentially. This approach is rather popular within open-source
development. Semantic Release library helps to tune the project to
integrate this process transparently.
The third point is similar to the first one. Though there are differences.
Suppose that we have two primary branches in our repository.
The develop branch and the master one. The develop contains the most
relevant changes. While the second one has only releases. If we need to
deploy the master branch only, there is no need to trigger the CD job on
merge to the develop.
The last point is the aggregate of all the approaches. For instance,
the develop branch might be deployed according to the schedule to the
dev environment. And the master is deployed to the production on each
Pull Request merge.
Tools
The market offers dozens of solutions to automate CI/CD processes.
Let’s take a look at some of them.