GitLab CI/CD explained: Features, pricing, and quick tutorial

What is GitLab CI/CD?

GitLab CI/CD is a component of GitLab that automates software build, test, and deployment processes. CI/CD stands for Continuous Integration and Continuous Deployment, a practice for streamlining and automating software development workflows. GitLab CI/CD provides developers the tools to automate testing, build software, and deploy it efficiently.

GitLab offers a unified experience, combining version control and CI/CD in a single platform. By leveraging GitLab CI/CD, development teams can ensure code quality while rapidly releasing software. However, GitLab is considered a lightweight CI/CD tool and might not be suitable for Continuous Delivery or deployment of complex software projects. In these scenarios, it is often used together with a full-featured deployment automation solution.

Key components of GitLab CI/CD

GitLab CI/CD comprises several components for automating software processes.

GitLab runners

GitLab runners are system processes that execute jobs in pipelines as specified in a .gitlab-ci.yml configuration file. They can be shared, used by multiple projects, or specific to one, providing flexibility for varying project needs. Runners can operate on virtual machines, bare-metal, Docker containers, or Kubernetes clusters, illustrating their adaptability in different development environments.

Runners are versatile, supporting various tools and languages. They also handle pipeline jobs asynchronously, enabling simultaneous execution. Additionally, custom environments ensure consistency in job execution. Runners are central to GitLab’s strategy for fast, reliable, and modular automated software delivery.

The .gitlab-ci.yml file

The .gitlab-ci.yml file is a YAML configuration file located at the root of a GitLab repository. It defines the CI/CD pipeline configuration specifying how jobs are run, the stages they belong to, the triggers, and dependencies among them. Through this file, developers dictate what happens in continuous integration, using it to run tests, build applications, and deploy them. It reflects a project’s pipeline structure, making it visible and repeatable.

A well-structured .gitlab-ci.yml file improves the readability and maintainability of pipelines, which is crucial for large or evolving projects. It adapts pipeline logic to dynamic requirements like conditional execution. Modularity in configuration allows teams to implement reusable templates within the YAML.

CI/CD variables

CI/CD variables in GitLab allow for dynamic customization of jobs and stages during pipeline execution. These variables can store parameters, secrets like API keys, or simple environment settings, making them useful for environment-specific configurations. They are defined in the GitLab interface or directly in the job scripts, providing versatility in setting context-sensitive information.

Variables simplify complex configurations by segregating environment-sensitive data from core logic. By isolating this dynamic information, they prevent hard-coded values, thus maintaining cleaner, more maintainable pipelines. Additionally, variables can be protected and secured, ensuring sensitive information remains confidential while still accessible to relevant processes.

Pipelines and jobs

A pipeline represents the workflow that consists of sequential stages, each containing jobs performing different tasks. Jobs execute scripts, which build, test, or deploy code, acting as building blocks for the larger pipeline. Defined in the .gitlab-ci.yml file, pipelines organize jobs to reflect logical progressions from code development to deployment.

The orchestration of jobs into pipelines ensures tasks run in order, with dependencies honored. This minimizes conflicts within the processes and maximizes resource utilization. Pipelines’ flexibility allows various job execution patterns such as parallel or serial, optimizing performance, especially in larger projects with significant computational loads.

GitLab CI/CD pricing

GitLab CI/CD is available as part of the GitLab platform, which offers three tiered pricing plans.

Pricing below is for the SaaS version of the platform. There are also options available for on-premise deployment of GitHub and dedicated SaaS hosting for enterprises or government users.

Free plan

The Free plan provides essential CI/CD capabilities for personal projects and small teams. It includes:

• 400 compute minutes per month
• 5 users per top-level group

This is suitable for developers or teams just starting with GitLab CI/CD, offering sufficient resources to automate testing and deployments without financial commitment.

Premium plan

The Premium plan, priced at $29 per user/month (billed annually), is for scaling organizations and multi-team usage. In addition to the Free plan features, it offers:

• 10,000 compute minutes per month
• Features like code ownership, merge request approval rules, and advanced CI/CD capabilities
• Enterprise user and incident management and dedicated support

This plan supports larger teams that require structured workflows, automation, and collaboration across multiple projects.

Ultimate plan

The Ultimate plan is tailored for enterprises needing stronger CI/CD capabilities, organization-wide security, compliance, and advanced planning. Features include:

• 50,000 compute minutes per month
• Dynamic and static application security testing
• Vulnerability management and dependency scanning
• Advanced planning tools like multi-level epics and portfolio management
• Free guest users

Pricing for the Ultimate plan is available upon request.

Quick tutorial: Getting started with GitLab CI/CD

To get started with GitLab CI/CD, you will create and run your first pipeline by defining jobs and stages in a .gitlab-ci.yml file. This tutorial guides you through the process of setting up a basic CI/CD pipeline. Instructions are adapted from the GitLab documentation.

Prerequisites

Before proceeding, ensure you have the following:

1. A GitLab project where you want to use CI/CD.
2. Maintainer or Owner role for the project.
3. If you do not have a project, create a public project for free on the GitLab website.

Step 1: Ensure you have runners available

Runners are essential components in GitLab CI/CD that execute the jobs defined in your pipeline.

To check for available runners:

1. Go to Settings > CI/CD in your GitLab project.
2. Expand the Runners section.
3. Verify that at least one runner is active. An active runner has a green circle next to it.

If you do not have a runner:

1. Install GitLab Runner on your local machine.
2. Register the runner for your project and select the shell executor.

Step 2: Create a .gitlab-ci.yml file

The .gitlab-ci.yml file is a YAML configuration file located at the root of your repository. It defines the CI/CD pipeline, including the jobs, stages, and any conditional logic.

To create this file:

1. Navigate to your project and select Code > Repository.

2. Click the New File button and name the file .gitlab-ci.yml.

3. Paste the following sample configuration into the file:

   build-job:
     stage: build
     script:
       - echo "Welcome, $GITLAB_USER_LOGIN!"
   
   test-job1:
     stage: test
     script:
       - echo "This job is a test"
   
   test-job2:
     stage: test
     script:
       - echo "This job is a test but takes longer than test-job1."
       - echo "When the echo commands are completed, it runs the sleep command for 30 seconds"
       - sleep 30
   
   deploy-prod:
     stage: deploy
     script:
       - echo "This job deploys an object from the $CI_COMMIT_BRANCH branch."
     environment: production

   This file defines four jobs:

   • build-job: Executes in the build stage and greets the user.
   • test-job1: Executes in the test stage and simulates a simple test.
   • test-job2: Also in the test stage, it simulates a longer-running test by using a sleep command.
   • deploy-prod: Executes in the deploy stage and simulates a deployment to production.

4. Commit the changes to your repository.

Step 3: View pipeline and job status

Once the .gitlab-ci.yml file is committed:

1. GitLab automatically triggers the pipeline.
2. To view pipeline status, navigate to Build, then Pipelines.
3. Select the pipeline ID to view a graphical representation of the stages and jobs.

You can click on individual job names (e.g., deploy-prod) to view job details, including logs, status, and timing information.

This basic setup forms the foundation for more advanced configurations, such as adding conditional logic, integrating tests, or deploying to cloud environments.

Best practices for GitLab CI/CD

Implementing best practices in GitLab CI/CD improves the effectiveness and reliability of continuous integration and delivery processes.

Security considerations in CI/CD pipelines

Security measures include using restricted access controls for sensitive CI/CD variables and setting up secure runners. Implementing version controls and audit trails ensure transparency and traceability of changes. Security tools integrated with pipelines provide automated scanning for vulnerabilities.

Securing the deployment environment requires encryption for data in transit and at rest and verifying code authenticity before deployment. Establishing a security baseline and conducting regular audits ensure compliance with industry standards. Proper security measures fortify CI/CD pipelines against potential threats, preserving the integrity and confidentiality of software development and deployment processes.

Optimizing pipeline performance

Optimizing pipeline performance ensures efficient CI/CD processes and minimizes bottlenecks in development and deployment. This involves analyzing execution times, identifying slow jobs or stages, and using strategies like parallel processing. Breaking down tasks into smaller, manageable jobs or leveraging efficient algorithms within scripts can reduce execution time.

Strategically utilizing caching and artifacts reduces redundancy and expedites repeated tasks. Review the .gitlab-ci.yml file to refine stage dependencies and optimize execution order. Monitoring resource consumption helps adjust runner environments to match job requirements better. By fine-tuning pipeline configurations, teams can achieve faster iterations.

Handling pipeline failures and troubleshooting

Effective troubleshooting involves identifying errors quickly, examining logs, and employing consistent testing procedures to uncover the source of issues. Integrating alert systems notifies teams of pipeline breakdowns, allowing swift resolution. Comprehensive documentation of troubleshooting processes aids in future reference and knowledge transfer within teams.

Regularly reviewing and refining test suites ensure their effectiveness, reducing false positives, or negatives that cause pipeline faults. Utilizing rollback mechanisms enables the reversal of failed deployments to prior stable states, minimizing downtime. Proactively addressing pipeline weaknesses and refining processes enables uninterrupted software delivery.

Using templates and shared configurations

Using templates and shared configurations improves CI/CD efficiency by promoting reusability and consistency across projects. Templates provide predefined configurations for common tasks, reducing setup time, and standardizing pipeline processes. Shared configurations consolidate settings and scripts, ensuring uniformity and reducing duplication errors.

Developers can use GitLab’s include feature to integrate these configurations seamlessly into the .gitlab-ci.yml file, enabling centralized management of repetitive tasks. This reduces maintenance overhead and simplifies updates or modifications, ensuring projects remain synchronized.

Monitoring and reporting

Monitoring and reporting in GitLab CI/CD involve tracking pipeline performance and generating insights into processes. Continuous monitoring identifies trends, anomalies, and performance bottlenecks, providing tangible data for operational improvements. Employing tools to visualize pipeline metrics and output lets teams assess efficiency comprehensively.

Automated reporting offers real-time feedback on builds, tests, and deployments, improving accountability and transparency. Detailed reports enable performance reviews, enabling teams to pinpoint areas for process improvements and conduct deeper analysis regularly. Effective monitoring and reporting support data-driven decision-making.

Extend GitLab with Octopus to add best-in-class CD

CI is not CD. Most all-in-one CI/CD tools weren’t designed to handle the complexities of CD at scale. Octopus was, and it makes it simple.

At the start, most CI/CD tools can handle the basics. But as your applications evolve and become more complex, your deployment scripts become thousands of lines of code you need to manage. All-in-one tools are still a box of parts that need building. They don’t ‘just work’.

Octopus takes over from your CI tool and handles CD release, deployment, and operations in advanced ways that no CI tool can. Teams using Octopus don’t fear deployments—they embrace them. With Octopus, deploying to production isn’t a high-stakes event that requires overtime and anxiety. It’s a non-event so routine and seamless that you can confidently do it anytime.

You can read more about Octopus Deploy’s features or try it out for yourself with a free trial.

Help us continuously improve

Please let us know if you have any feedback about this page.

Send feedback