GitLab CI/CD Pipelines for Beginners

A CI/CD pipeline is a series of steps that you can use to automate the software development and delivery process.Just as making a great pizza involves multiple steps and coordination among different roles, CI/CD involves various stages, tools, and team collaboration to deliver software efficiently and reliably. So, let us embark on this delicious journey through the world of CI/CD, using the art of pizza-making as our guide.

Imagine you’re in the business of making the perfect pizza. Whether you’re a pizza enthusiast or a professional pizzaiolo, you know that crafting a flawless pizza requires precision, teamwork, and a streamlined process. In many ways, this pizza-making journey is similar to the world of software development, where teams work tirelessly to create and deliver high-quality software products.

Roles of different components in Gitlab CICD

Just as different individuals and objects like the Chef, Recipe, Ingredients, Suppliers, Delivery Agent, and Customers play distinct roles in the pizza making and delivery process, a CI/CD pipeline employs various agents to carry out specific tasks within the software building and delivery process. The main actors in the process are:

Gitlab Runner

Picture GitLab Runners as tireless agents, each with a unique role in running their tasks in the most specialized of environments. Just as a skilled Chef takes charge of tasks within the kitchen and a delivery person handles responsibilities outside the shop premises, GitLab Runners can efficiently perform their tasks across various platforms and environments.

In Gitlab these runners can run on physical machines or virtual instances. It can be installed on various platforms (Windows, Linux, macOS) and can execute tasks within Docker containers or directly on the host system. The runner could be shared runners which are configured at the Gitlab instance level and can be used by any project. But one can set up their own runners on their infrastructure for private or specific use cases.

GitLab CI/CD Configuration File (.gitlab-ci.yml)

Could a process be considered successful if it is not structured in a way that meets the needs of the solution? What happens if the devlivery person deliver the Dough to the customer? No, it is not what is expected from the pizza delivery process. Any supply chain should have a list of tasks, its order of execution, who should execute the task and what objects could be used in the execution of it. .gitlab-ci.yml file is at the heart of defining the CI/CD pipeline.

In GitLab CI/CD, the .gitlab-ci.yml file is used to define the jobs, stages, scripts, and rules for the pipeline. The dependencies structured among the jobs in a pipeline in turn helps form the Directed Acyclic Graph (DAG) that represents the pipeline’s workflow.

GitLab CI/CD Pipeline

A Gitlab pipeline is an assembly and devlivery pipeline which has a series of stages and jobs defined in the .gitlab-ci.yml file. The jobs in the pipeline could be executed sequentially or in parallel depending on the configuration.

If the pipeline is a complex and lengthy pipeline then it can be split and modularize into smaller, more manageable child pipelines. Child pipelines allow for better organization of tasks, easier code reusability, and improved visibility into different stages of the pipeline. Child pipelines can be triggered from a parent pipeline, and they can be defined in separate repository files or templates, enhancing the flexibility and scalability of GitLab CI/CD configurations.

Executors

In GitLab CI/CD, executors refer to the environments where jobs within a pipeline are run. They determine the underlying infrastructure and resources for running CI/CD tasks. GitLab supports various executor types, including Docker, Shell, and Kubernetes, each with its own characteristics.

Docker executors in GitLab allow to run the CI/CD jobs in a clean and isolated environment, using Docker images. This can help to improve the consistency and reliability of the builds, and make it easier to manage dependencies.

Shell executors run jobs directly on the GitLab runner host without containerization, offering simplicity but potentially less isolation.

Kubernetes executors deploy jobs to a Kubernetes cluster, leveraging the scalability and resource management capabilities of Kubernetes for running CI/CD tasks. They are suitable for more complex and scalable CI/CD workflows.

GitLab Runner Manager

The Restaurant Manager, in a pizza delivery scenario, ensure that orders are received, processed, and dispatched efficiently. Just as the restaurant manager the GitLab Runner Manager manages the runner instances. It schedules and distributes jobs to available runners based on the runner’s tags and capabilities.

GitLab Web Interface

The GitLab web interface helps to configure, monitor, and manage your CI/CD pipelines. It can be used to view pipeline status, logs, and artifacts, as well as manage environment variables and other CI/CD settings that required for the successful execution of pipeline jobs.

Container Registry

A Container Registry is where Docker images can be stored and managed. The images from it can be used in the CI/CD pipelines to ensure consistency between development, testing, and production environments.When a job is initiated by a Docker or Kubernetes runner, it fetches and deploys the Docker image to execute the assigned scripts, ensuring a consistent and reproducible workflow.

Artifacts

In GitLab, a job can generate various artifacts, such as compiled binaries, packaged code, reports, and job logs. These artifacts can be stored either locally on the runner where the job is executed or uploaded to a remote location, like an object store or a network file share. Importantly, these artifacts created in one stage of a pipeline can be accessed and utilized in subsequent stages of the same pipeline or in child pipeline, facilitating the sharing of essential data and results across the pipeline’s workflow.

Considering that artifacts can occupy storage space, it’s advisable to set an expiration time for these generated artifacts. The expiration time for artifacts can be configured within the job configuration section of .gitlab-ci.yml file. This controls how long these artifacts are retained before they are automatically removed and in turn manage storage resources efficiently.

Conclusion

In the first part of this series on Gitlab CICD, we explored the key roles played by various participants in the GitLab CI/CD process. System administrators are responsible for configuring elements like runners and artifact storage locations, as well as other instance-level settings. On the other hand, the task of configuring the pipeline, as defined in the .gitlab-ci.yml file, falls under the domain of either a DevOps engineer or a developer.