Introduction to CI/CD

What is CI?

Continuous integration is usually done in the form where all developers push the code onto a shared repository mostly multiple times a day. It is pretty fit for a project that should be coded and developed on different platforms with multiple tools. Currently, it has become important to have such a mechanism in place to integrate and validate the changes made to the code in a parallel way.

What is CD?

Continuous delivery usually means a developer’s changes to an application are automatically bug tested and uploaded to a repository , where they can then be deployed to a live production environment by the operations team. It’s an answer to the problem of poor visibility and communication between dev and business teams. To that end, the purpose of continuous delivery is to ensure that it takes minimal effort to deploy new code.

Continuous deployment (the other possible “CD”) can refer to automatically releasing a developer’s changes from the repository to production, where it is usable by customers. It addresses the problem of overloading operations teams with manual processes that slow down app delivery. It builds on the benefits of continuous delivery by automating the next stage in the pipeline.

Together CI and CD(referred as CI/CD) introduces ongoing automation and continuous monitoring throughout the lifecycle of apps, from integration and testing phases to delivery and deployment.

Let’s talk more about CI

What is Jenkins? How is Jenkins used for CI?

Jenkins is an automation tool written in Java with built-in plugins for continuous integration tasks. It is used to continuously build and test projects making it easier to integrate the changing codes to it.

Jenkins allows for faster delivery of software by working with a large number of deployment and testing technologies. It also accelerates the development phase via the automation of tasks. It is primarily a server-based app and requires a web server like Tomcat.

Jenkins rose to fame because of its monitoring of repeated tasks. If a team is developing a project, then Jenkins will constantly check and evaluate the code thereby returning any possible error/failure early in the development phase.

Why use Continuous Integration with Jenkins

  • If the build is successful, then Jenkins will deploy the source into the test server and notifies the deployment team.
  • If the build fails, then Jenkins will notify the errors to the developer team.
  • The code is built immediately after any of the Developer commits.
  • The code is deployed after every successful build and test.

Jenkins Plugins

Use-case of jenkins

  1. Manual Tests option
    Sometimes things work great locally but fail when pushed on a central system. This happens because, by the time they push, things change. Continuous Integration tests the code against the current state of a code base and is done in the production-like environment.
  2. Increased Code Coverage
    CI servers such as Jenkins can check code for test coverage. Tests increases code coverage. This inspires transparency and accountability in team members. Results of tests are displayed on build pipeline which ensures team member follow required guild lines. Code coverage similar to code review ensures that testing is a transparent process among team members.
  3. Code deployment to Production
    Jenkins or another CI system can deploy code to staging or production automatically if all the tests written for the same within a specific feature or release branch are green. This is formally known as Continuous Deployment as well. Changes before a merge activity can be made visible too. This can be done in a dynamic staging environment, and after they are merged it is deployed directly to a central staging system, pre-production system or even a production environment.

RHEL8 | AWS | Ansible | Docker| K8s | Jenkins