Last Updated on February 9, 2023

We have distinguished several projects on the version control systems market for years. One of the main ones is undoubtedly GitLab, which has undergone such a significant metamorphosis that it is now presenting itself as a platform for DevOps. Is GitLab really such a platform? What is this whole GitLab CI/CD, and why do you need it.

DevOps

Every day, in the IT world, we deal with more minor or more significant breakthroughs, discoveries, etc. There are several milestones in the history of IT development that know the so-called rules of the game. It is enough to mention the containers, whether Docker or Kubernetes or the currently loved cloud, to understand the author’s meaning here. Such a change was behind the rise of the DevOps movement, which was intended to connect the world of developers with the world of admins. It is worth knowing that a DevOps specialist is currently an IT handyman – he will write the code and will take care of the operation of the server itself. Of course, I allowed myself to make a joke here, but you have to admit that there is something to it.

One of the main assumptions, as we have already established of the DevOps movement, was to connect the world of developers and administrators. In some ways, and on some levels, this has been achieved. A perfect example of this is GitLab, which has been developing its platform for production and project management for years. GitLab is currently not just a version control system but a complete software development product. This means that thanks to the provided tools, we will be able to plan, develop and analyze a given project.

GitLab CI/CD

GitLab’s approach to version control systems is quite different than, for example, GitHub. GitLab focuses on providing a comprehensive platform that is to help us in programming but also in planning and managing it. GitLab currently puts a lot of emphasis on the CI/CD approach, but what does it really mean? In short, you could say that this is a continuous software development method, but it would not be entirely accurate. To completely understand this approach to creating projects, we need to dig into the CI/CD acronym.

Continuous Integration

GitLab perfectly understands that the code of a given product is often changed several dozen times a day. For this reason, GitLab provides us with tools that allow us to automate, and thus, for example, with each push to the repository, execute scripts that will build and test our application. It is a methodology known since the nineties that enables multiple changes in the code with the behavior of tests and compilations of the application. According to this approach, the project should be built and tested after each commit. This not only speeds up the work on a given project but also allows you to quickly diagnose problems such as the extended build or deployment time of the application itself or errors resulting from faulty code changes. The truth is that most programmers prefer to program rather than test code again and again, and the mere possibility of automating the tests for an application or a given module is a much-liked feature.

Setting CI/CD pipeline? Then don’t forget about backup. Secure your code with the first professional GitLab backup.

Start 14 days free GitProtect trial

Continuous Delivery and Continuous Deployment

GitLab, along with the Continuous Integration methodology, implemented tools that allow us to carry out automatic deployment along with publication. However, not every team wants a given application to be automatically deployed and published, which is why GitLab allows you to choose the method of publication here:

  • Continuous Delivery: every time the code is changed, our application is automatically deployed. After this action, the team gets the option of publishing, and this is an option that the user needs to perform manually. This means that it is the human who finally decides whether to publish a given deployment or not.
  • Continuous Deployment: this is precisely the same scenario as in the above approach, i.e., after each code commit, our project is automatically deployed. However, such deployment is also followed by an automatic publication that does not require any human response in this approach.

Thanks to the use of CI/CD, we can accelerate and fully control the project and its changes. Automatic tests and deployment are features that every team will appreciate. We all knew that deploying without tests means FIRE. Of course, we must not forget that we can always roll back, and using this approach does not force us to publish automatically. In short, we get a tool that will allow us to perform continuous integration.

Get free trial

Preparations

GitLab enables CI/CD functionality by default with each new project, but it should be mentioned here that we are not forced to use these features. I believe that the possibility of choice is very welcome nowadays and the possibility of turning off the CI / CD for a given project, or also for all new ones. However, once we decide that our project should be implemented in the continuous integration way, we only need to know if our project will be migrated from another CI/CD tool (Migrating from CircleCI or Migrating from Jenkins), which is also an interesting issue, or maybe we are transforming our current project. There are a few prerequisites that we should meet before using GitLab CI/CD: 

  • Check if we have available runners. We can do it by going to Settings -> CI/CD and expanding Runners. We should find at least one runner with a green circle next to it – then we are ready to go. However, if, for some reason, we do not have active runners, we have to download and install them.
  • Next, we need the CI/CD configuration file. GitLab uses the well-known YAML language for this purpose. Here is a slight digression. YAML is a prevalent language for presenting data structured, but you have to be very careful when using it. The languages, as the name suggests, relies entirely on the structure. This means that one white space and the entire file are not validating. In the case of GitLab, in the .gitlab-ci.yml file, we will save all the instructions and automatic calls that we will use for a given project. An example of such a file:
build-job:
  stage: build
  script:
echo “Hi, $GITLAB_USER_LOGIN”

  test-job:
    stage: test
    script:
echo “Xopero and even log4j isn’t so scary!”

  deploy-prod:
    stage: deploy
    script:
echo “$CI_COMMIT_BRANCH - deploy from branch”

Of course, we can use variables and even entire scripts that run containers in the background. In the example above, we used $GITLAB_USER_LOGIN and $CI_COMMIT_BRANCH, which are so-called predefined variables. We can also use ready-made templates here. More on variables, pipelines, and templates in the next post.

Summarizing

GitLab CI/CD is an excellent collection of tools for our projects’ production, management, and continuous improvement. Automating tests and deployment of the project itself are the main advantages, but it should not be forgotten that there are other benefits associated with it. One of them is undoubtedly a large number of ready-made templates that we can use to accelerate the production of applications significantly. However, GitLab will not protect us from unforeseen events; this is what we can expect mainly from a good GitLab backup. We will be able to provide this crucial way to secure your data with GitProtect. Then, and only then you can truly focus on content management systems.

What if your organization uses a different git platform provider? We are covering CI/CD topics quite extensively, you can check our other article concerning GitHub CI/CD. We are providing some vital suggestions and best practices.

Comments are closed.

You may also like