What is CI?
Continuous integration (CI) happens to be one of the most vital parts of DevOps. It is primarily used to integrate various stages of DevOps together. In other words, it is a coding practice that essentially enables the development team to make and implement small changes in the code and version control methods quite frequently.
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?
The “CD” in CI/CD refers to continuous delivery and/or continuous deployment, which are related concepts that sometimes get used interchangeably. Both are about automating further stages of the pipeline, but they’re sometimes used separately to illustrate just how much automation is happening.
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
- The code is built and test as soon as Developer commits code. Jenkin will build and test code many times during the day
- 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
By default, Jenkins comes with a limited set of features. If you want to integrate your Jenkins installation with version control tools like Git, then you need to install plugins related to Git. In fact, for integration with tools like Maven, Amazon EC2, you need to install respective plugins in your Jenkins.In short if I say there are many plugin for Jenkins install them according to your requirement.
Use-case of jenkins
- Decrease Code Review Time
CI systems such as Jenkins and Version Control System such as Git can communicate with each other and inform the users when a merge request is suitable for merge. - 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. - 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. - 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.
