GitLab — basics, features and CI/CD

What is GitLab?

GitLab — is a full-featured open-source DevOps platform under the MIT license. Unlike GitHub, which combines various services through integrations, GitLab provides a single tool for the entire development lifecycle: from code management and code review to CI/CD, monitoring, security, and deployment. The platform does not require third-party services for most DevOps tasks.

The history of GitLab began in 2011 as an internal project by Ukrainian developers. The first public release came out in September 2011, and in 2015 GitLab became the first project on GitLab.com, launching cloud hosting. In 2017, GitLab carried out a painful but instructive migration process — moving the entire infrastructure from Azure to Google Cloud, which was conducted live and documented in a series of blog posts.

GitLab’s architecture consists of three main components: GitLab Rails (web application on Ruby on Rails), GitLab Shell (handling Git operations via SSH), and Gitaly (gRPC server for accessing Git data). CI/CD is handled by GitLab Runner — a separate application installed on build servers that executes jobs in isolated environments (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: pipelines and runners

GitLab CI/CD — is a built-in continuous integration and delivery system that is a key advantage of the platform. Unlike GitHub Actions, GitLab CI/CD was built into the architecture from the start and requires no separate setup: every project automatically gets CI/CD once the .gitlab-ci.yml file is added to the repository root.

A pipeline consists of stages that run sequentially or in parallel: build → test → deploy. Each stage contains one or more jobs that run on runners. If a job in a stage fails, the entire stage is marked as failed, and subsequent stages do not run by default. Below is an example pipeline for a mobile project:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runner supports several executors: Docker (recommended), Kubernetes, SSH, VirtualBox, and Parallels. The most popular option is the Docker executor, which runs each job in a separate container. A runner can be registered as specific to one project or as shared for an entire group. GitLab.com provides free shared runners with a limit of 2000 minutes per month.

Advanced CI/CD features

GitLab CI/CD supports manual triggers (when: manual), delayed triggers (when: delayed), parallel execution (parallel: 5), matrix builds, dynamic pipelines (child pipelines), and multi-level pipelines (parent-child). This allows building complex scenarios: for example, dynamically generating a pipeline for each module in a monorepo or running parallel builds for different Android architectures (arm64, x86_64).

GitLab vs GitHub: key differences

GitLab and GitHub — are two main competitors in the Git platform market, but their philosophy and architecture differ fundamentally. GitHub focuses on open community, an ecosystem of integrations, and social features (forks, stars). GitLab focuses on a comprehensive DevOps cycle and provides all tools out of the box: from planning to monitoring.

The main architectural difference: GitLab — is a single monolithic application that developers install as a whole. All features (CI/CD, Container Registry, Security Scanning, Pages) are built-in and work immediately after installation. GitHub is a platform with an API where most features are implemented through integration with third-party services: Travis CI, CircleCI, Jenkins, SonarQube. The table below compares key characteristics:

The choice between GitLab and GitHub depends on team needs. If the priority is rapid deployment with zero configuration and an open community — choose GitHub. If you need full infrastructure control, self-hosted deployment, and built-in security — GitLab is preferable. According to a Stack Overflow survey (2024), 90% of developers use GitHub, 33% use GitLab (often both platforms simultaneously).

Self-Managed GitLab: installation on your own server

Self-Managed GitLab (formerly On-Premises) allows you to install the platform on your own server and have full control over data, infrastructure, and uptime. This is especially important for organizations with compliance requirements: financial sector, government institutions, medical organizations where data cannot be stored on third-party servers.

GitLab installation is supported on Ubuntu, Debian, CentOS, and via Docker. The official Omnibus package includes all components: web server (NGINX), database (PostgreSQL), cache (Redis), Git handler (Gitaly), and background processes. Minimum requirements: 4 GB RAM and 2 CPU for teams up to 100 people. For large installations with high load, it is recommended to split components across separate servers.

# Installing GitLab CE on Ubuntu via Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# Installing the package
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# Viewing status
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab has no CI/CD minute limits — all runners belong to the organization, and their power is limited only by your own hardware. Also available are Geo-replication for regions, audit logs, IP blocking, and integration with corporate LDAP/SAML providers. GitLab releases updates every month (on the 22nd) with new features and security fixes.

Built-in GitLab security tools

Security in GitLab is built into the platform level and includes several scanners that work at every pipeline stage. SAST (Static Application Security Testing) analyzes source code for vulnerabilities without executing the application, supporting over 15 languages including Java, Kotlin, Swift, Python, and JavaScript. DAST (Dynamic Application Security Testing) tests running web applications for vulnerabilities from within.

Additional tools: Container Scanning checks Docker images for vulnerabilities in base layers; Dependency Scanning analyzes project dependencies and warns about known CVEs; Secret Detection finds accidentally committed API keys, passwords, and tokens; Fuzz Testing performs automated testing with malformed data to find non-obvious bugs. All scan results are displayed in a unified Security Dashboard.

GitLab also provides Compliance — tools for meeting regulatory requirements. The Compliance Dashboard shows the compliance status of all projects, Audit Events logs every administrator and developer action, and Compliance Frameworks allow enforcing configuration policies for specific groups of projects. This makes GitLab a popular choice in enterprise environments with strict security requirements.

Container Registry and Dependency Proxy

GitLab Container Registry — is a built-in Docker registry integrated with CI/CD. After building a Docker image in a pipeline, it can be immediately published to the Registry using the environment variables CI_REGISTRY and CI_REGISTRY_USER. The Registry supports pull-through caching, tagging, cleanup policies, and vulnerability scanning directly in the registry.

Dependency Proxy — a caching mechanism for containers and images from external registries (Docker Hub, Quay, GCR). When a pipeline requests an image like ubuntu:latest, GitLab first checks its cache — if the image is already downloaded, it is not fetched again. This reduces load on external registries, speeds up pipelines, and protects against Docker Hub rate limits.

For mobile developers, GitLab provides GitLab Pages for hosting documentation and test reports. After running tests, artifacts (HTML reports, screenshots, logs) can be published as Pages and a link can be shared with the QA team. This is more convenient than uploading reports to cloud storage since everything resides within the same GitLab project.

GitLab API and Webhooks

GitLab API (REST and GraphQL) provides access to all platform resources: projects, users, pipelines, Merge Requests, registry. The API is used for automation: creating a project from a template, assigning a reviewer, getting pipeline status. Webhooks allow sending HTTP notifications to external systems on events: push, merge, issue creation. Webhooks integrate with Mattermost, Slack, Telegram, and internal monitoring systems.

GitLab Pages for mobile documentation

GitLab Pages automatically publishes static websites from a repository. For mobile projects, Pages is convenient for hosting API documentation, test coverage reports, and lint analysis results. Publishing happens automatically after a successful pipeline — simply add a deploy step in .gitlab-ci.yml with Pages publishing. The result is available at https://namespace.gitlab.io/project-name.