Modernize CI/CD using GITLAB CI

#CI/CD #DevOp #Gitlab

Context

Let’s put ourselves in the shoes of a developer who has spent days and nights working on a feature and developing the perfect code. The worst nightmare for him was when he merged his code and found a conflict because other developers were working on the same file. For no reason, he had to spend his precious time and energy comparing the conflicts, making adjustments, rerunning the tests before merging the code again, and so the story goes on.

CI/CD is here to recue him from this problem and providing many more value additions. CI works to address the above issue by frequently merging changes in a shared branch. This technique reduces the likelihood of merge conflicts as we are not waiting until the end of the coding phase to integrate separate branches. Due to frequent merges, any issues that do occur will be less complex and easier to resolve.

It’s not a new concept, and we are using it for years. In the initial days it was a luxury but now it has become necessity. In this agile world where “time to market” is so important, its difficult to imagine the delivery without CI/CD.

?CI/CD platforms

?CI/CD is just a methodology, and we need some efficient toolset to support it. There are many tools available in market and it is very difficult to make a choice. Few of the popular tools in this category are Jenkins, Gitlab, CloudBees, JFrog Software Supply Chain Platform, Azure DevOps Server, AWS CodePipeline , CircleCI and Bamboo. Exact choice of the tooling is always boiling down to actual use case.

Today we are going to explore GitLab CI but it is difficult to resist without starting with Jenkins - THE King of traditional CI servers. Whenever we talk about CI server, first thing which comes to mind is Jenkins. We are using Jenkins (originally Hudson) for more than a decade and it still enjoys around half of market share in continuous Integration tools category. Few things which make Jenkins indispensable are excellent community support, wide range of plugins, easy to setup & use, open source product and so on.

Jenkins can be your first love which is hard to forget but you will also appreciate that it was developed much before adoption of containerization, micro services & other cloud native technologies. Jenkins did well to support these technological changes with the addition of plugins but still the overall approach remained the same which resulted in some problems. Before you start coining me as “Jenkins hater”, I used Jenkins for many years and still it is quick solution for many use cases. Key problems with Jenkins are limited support for containers and micro services, scaling, heavy maintenance & unreliable third party plugins.

About Gitlab

GitLab is a web-based tool which provides a Git based repository, wiki, issue-tracking, CI/CD features and is available both as open-source and Enterprise product. Gitlab CI service is part of Gitlab that allows you to apply Continues Integration, Continues Delivery & Continues Deployment to your software with no third-party application or integration needed.

GitLab is a complete DevOps platform which is delivered as a single application. There is no need to integrate and synchronize external tools which will save the time required for handoffs. Everyone contributes to a single conversation, instead of managing multiple threads across different tools.

How it works

For using GitLab CI, a project is required in GitLab. CI/CD pipeline is configured using a file called .gitlab-ci.yml, this file defines the structure and order of the pipeline. For enabling CI/CD we just need to add this yaml file in the project root folder. This file contains stages like build, test & deploy. Tasks to be performed in each stage can be provided as scripts. On any push to your repository, GitLab will look for the .gitlab-ci.yml file and start jobs according to the contents of the file.

?For executing the job GitLab use runner which is lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab runners are used to run the jobs over multiple machines which can be on premise or any cloud. You can register the runner as shared ,group or specific after installing it. One GitLab runner can run multiple jobs concurrently. GitLab also provides enriched issue tracking including issue boards, milestones.

Please refer the below link for the detail working of GitLab CI -

https://docs.gitlab.com/ee/ci/

?

What makes GitLab indispensable

· Cost - Free and open source however enterprise edition is also available

· Integrated Toolset - Single tool for SCM, CI/CD , Issue tracking, Security testing and monitoring

· Easy maintenance - Easy to Maintain and upgrade, just need to replace one docker image

· Highly optimized for cloud native applications - Suitable for containers, it has built in container registry and kubernetes integration

· Highly Scalable - Scaling runners is quick and simple

· Auto Scaling - Gitlab runners can auto scale to optimize cost

· Observability - End-to-End Monitoring with packaged Prometheus

· Security - Two factor authentication for improved account security

· Feature Rich - Frequent addition of new feature (22nd of every month)

?Conclusion

?It is almost impossible to run a modern project without CI/CD. Among the numerous CI/CD platforms, the right choice depends on your use cases. Other factors that may influence your decision include cost, features, support, and industry analysis. All CI/CD platforms have advantages and disadvantages, depending on what your development team needs. Gitlab CI is suitable for most use cases, especially for applications with modern architecture, including microservices and containerization.