A CI/CD pipeline automates the software delivery process. It introduces automation and continuous monitoring throughout the lifecycle of a software product. It involves the integration and testing phase to delivery and deployment.
What is CI/CD?
Before understanding the CI/CD pipeline, let us try to understand Workflow.
For any software project, there are several organizational tasks. Apart from the tasks, there are issues that keep popping up from time to time.
These issues are assigned to any of the contributors, who create a branch and write code to fix the issue. Once the bug fix is reviewed, the branch is merged with the master branch.
This can be classified as a set of Actions or Workflow. Basically, something which causes a change in or to the code in a git-based repository can be classified as an Action.
Integration pipeline is also another set of actions where the updated code is tested, built and deployed.
As the size of the code and the number of contributors keeps on increasing, it gets tedious for the developers to keep track of all the actions happening on the repository. The complexity of the Integration pipeline also keeps increasing due to increased actions. Hence the need for Continuous Integration or CI/CD pipeline.
In a CI/CD pipeline, the workflow is executed automatically mostly without developer intervention.
Stages of CI/CD
Store Stage: CI/CD pipeline is triggered by a code repository. Any change in the program triggers a notification to the CI/CD tool that runs an equivalent pipeline.
Build Stage: Merging of source code and its dependencies. It is done mainly to build a runnable instance of software that you can potentially ship to the end-user.
Test Stage: execution of automated test cases to validate the behavior of the software. This stage prevents easily reproducible bugs from reaching the clients. It is the responsibility of developers to write automated tests.
Deploy Stage: The product goes live. Once the build has successfully passed through all the required test scenarios, it is ready to deploy to the live server.
CI/CD Pipeline using Jenkins
There are 3 main steps towards setting up your CI/CD pipeline using Jenkins.
Setup a repository
The repository must have all your business logic code, configuration and files, along with an additional Jenkinsfile. This file contains the configuration and flow of your pipeline with details about individual tasks like build, test and deploy.
Setting up Jenkins Job
To set up a Jenkins job, you need to select “New Item” from the left sidebar. Jenkins shows different options. Choose either pipeline or Multibranch pipeline.
After that, fill in the form with the configuration info like GitHub repository link, branch name which you want to continuously build etc.
In the script path option, mention the relative path for Jenkinsfile under your code repository.
Save to successfully create your Jenkins job.
In your GitHub repository, navigate to Settings, Webhooks and Add webhook.
Fill the payload URL as the Jenkins server with GitHub-webhook/ appended and content type as application/JSON.
Leave the rest as it is and add a webhook.
Cool, once all this is done, go to your Jenkins item which you created and click on Build now from the left sidebar. This will sync up the webhook with the Jenkins server and trigger the build for the first time.
From here on out, any code push to any of the branches you specified will trigger a build continuously.
Also, Jenkins can be configured with cloud platforms like AWS, Azure or GCP for continuous deployment or CD.
As a convention for software projects, after the build step, the code is packaged as a docker image and deployed on Docker/Kubernetes cluster.
You can configure your Jenkins build to package your code into Docker image in a continuous manner, each new code into a new docker image.
Furthermore, configuring another pipeline between Jenkins and the cloud platform can ensure continuous integration and deployment of code without any developer intervention.