CI/CD is a software development practice where changes made by developers are pushed to the central repositories. Where CI stands for Continuous Integration and CD stands for Continuous Delivery/Deployment. This automates the software from integration and testing phases to delivery and deployment phases.
Continuous Integration is a way of continuously building and testing the code. It is usually used with SCM(Source Code Manager), when SCM is triggered CI begins to build and run tests. CI helps developers to merge their code changes and validate by automatically building the application and running different levels of automated testings like unit tests and integration tests. If anything wrong goes with automated testing, It throws errors and makes them easier to fix.
After CI pipeline Continuous Delivery automates the release of that validated and tested codes.
And Continuous Deployment automates the production release of the product, after successful and well-designed test automation.
Why CI/CD?
CI/CD is the best practice for you and your team to get instant feedback either from customers or your own team. Some of the benefits of using CI/CD pipeline for software development are as follows:
- Reduce Costs Using CI/CD pipeline helps to reduce the cost as it reduces the number of errors during SDLC.
- Less amount of code changes When you set up CI/CD, it helps to integrate even small pieces of changes on codes. This definitely makes developers identify the problems easily.
- Faster release Since failures or bugs are detected faster, they can be repaired or fixed faster, leading to a faster release rate.
- Test reliability As changes in the system are well tested, it makes the system more accurate and positive.
CI/CD Pipeline
Normally, CI/CD pipeline is a path for delivering a change that starts from development to delivery and deployment. CI/CD pipeline consists of the following steps:
step-1: Push Changes
Developers make changes to code and commit them to the repository.
step-2: Automated Tests
Automated tests are run like unit tests, validation tests, etc.
step-3: Build
Source code from the repository is built from build scrips to create a new application.
step-4: Deploy
Deploy the build version to the environment(dev, prod, staging, UAT, etc)
Popular CI/CD Tools
There are several CI/CD tools with their own benefits(GitLab CI/CD, GitHub Actions, Jenkins, CircleCI, TeamCity, Bamboo, Travis CI, Buddy, etc). In this, I’m going to mention some pf very popular CI/CD tools: GitLab CI/CD, GitHub Actions, and Jenkins.
GitLab CI/CD
GitLab offers a thorough software delivery platform that includes a free open-sourced version and features available for paid. GitLab CI/Cd is one of the most used features as a DevOps. All the software delivery fundamentals exist in GitLab but it lacks advanced governance features such as automatic verification and automatic rollbacks.
GitLab has some difficulty as well. If you want to use any of the GitLab tools, you need to use other GitLab tools. So if your team decides to use GitLab, you’ll have to leave behind what’s familiar and switch to something new. So, GitLab is a complete package itself.
GitLab Features:
- Terraform Provisioner
- GitOps
- Project planning
- Continuous Integration
- Continuous Deployment
- Source code management
- Manual verification
It has GitLab Runner, which is a separate program that can be run locally, in docker-machine, or in other VMs.
In GitLab CI/CD, one can execute the jobs faster by setting up their own runner(an application that processes the builds) with all dependencies which are pre-installed.
Jenkins
Jenkins is the most popular open-source tool that is used for both Continuous Integration and Continuous Deployment. Since it is open-source, it is free to use for all and there is a huge community following which leads to extra support, documentation, and features. This continuous integration tool is a Java-based open-source application. It is available for most major operating systems such as Linux, MacOS, and Windows.
Benefits of Jenkins:
- Open-source with great community support
- Easy to install
- 1000+ plugins support
- Free of cost
- Portable to all major platforms
GitHub Actions
Compared to other CI/CD tools, GitHub Actions offers native capabilities right in GitHub flow. It has more than 10,000 pre-written and tested automation and CI/CD actions in the GitHub Marketplace. The best part is unlike GitLab or others, it supports a webhook trigger in your GitHub repository, so you can trigger from a third-party tool also.
Benefits of GitHub Actions:
- GitHub flow It gives the ability to implement powerful automation. One can create own actions or use pre-written automation from the GitHub Marketplace.
- Hosted VMs on multiple OS GitHub Action offers hosted VMs with Ubuntu, Windows, MacOS. One can build, test and deploy directly to the OS of their choice or all three at the same time.
- Container and OS testing Actions support Docker and VMs which makes it easy to build and test the code across any system and automate workflows too.
- Use on the public repository for free GitHub Actions is free to use on all public repositories, which is one of the best features.
Example-1: Creating the First CI/CD pipeline with GitLab
In this section, we’re going to create a CI/CD for a sample project. For this go to GitLab and create a new project and clone it to a local folder.
Then go to CI/CD option from the sidebar as shown in the figure below. There you can see some sample CI/CD templates as well. I am creating a customized pipeline so I am using the editor option.
Go to the editor tab and Create a new CI/CD file. And click on Configure pipeline, it will create a .gitlab-ci.yml file which is the required pipeline file.
Now the .gitlab-ci.yml file has a default example of multi-staged pipeline configuration — test, build and deploy. The build-job runs first at the build stage and doesn’t depend on the stage. The script command under build-jb is required as it runs the commands specified.
The unit-test-job runs the test stage and depends on build stage, which means it only starts if build stage is completed successfully. The lint-test-job can run parallelly with the unit-test-job.
The deploy-job runs in the deploy stage if both build and test jobs are successfully executed.
Change every job as per your requirements.
To run the pipeline commit the file and it will start automatically.
To run the job you can use shared runners or your own runners after configuring them. You can enable or disable it by going to settings > CI/CD > Runner.
That’s it you’ve successfully configured the first CI/CD pipeline in GitLab. Now check if the pipeline is running or not.
