GitLab — основи, възможности и CI/CD

Какво е GitLab?

GitLab — е пълноценна DevOps платформа с отворен код под лиценз MIT. За разлика от GitHub, който обединява различни услуги чрез интеграции, GitLab предоставя единен инструмент за целия жизнен цикъл на разработката: от управление на код и code review до CI/CD, мониторинг, сигурност и развъртване. Платформата не изисква услуги на трети страни за повечето задачи на DevOps.

Историята на GitLab започна през 2011 година като вътрешен проект на украински разработчици. Първата публична версия изляза през септември 2011 година, а през 2015 година GitLab става първият проект в GitLab.com, пускайки облачен хостинг. През 2017 година GitLab извърши болезнен, но показателен миграционен процес — пренос на цялата инфраструктура от Azure в Google Cloud, който беше излъчен на живо и документиран в поредица публикации.

Архитектурата на GitLab се състои от три основни компонента: GitLab Rails (уеб приложение на Ruby on Rails), GitLab Shell (обработка на Git операции чрез SSH) и Gitaly (gRPC сървър за достъп до Git данни). CI/CD се осигурява чрез GitLab Runner — отделно приложение, което се инсталира на сървърите за изграждане и изпълнява job-ове в изолирани среди (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: pipeline-и и runner-и

GitLab CI/CD — е вградена система за непрекъсната интеграция и доставка, която е ключово предимство на платформата. За разлика от GitHub Actions, GitLab CI/CD беше вграден в архитектурата от самото начало и не изисква отделна конфигурация: всеки проект автоматично получава CI/CD след добавяне на файл .gitlab-ci.yml в корена на репозиториума.

Pipeline (pipeline) се състои от етапи (stages), които се изпълняват последователно или паралелно: build → test → deploy. Всяка етапа съдържа един или повече job-ове, които се изпълняват на runner-и. Ако един job в етапа завърши с грешка, цялата етапа се маркира като failed и следващите етапи не се пускат по подразбиране. По-долу е пример на pipeline за мобилен проект:

# .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 поддържа няколко executor (изпълнители): Docker (препоръчва се), Kubernetes, SSH, VirtualBox и Parallels. Най-популярният вариант е Docker изпълнителят, който пуска всеки job в отделен контейнер. Runner може да бъде регистриран като специфичен за един проект или като общ (shared) за цялата група. GitLab.com предоставя безплатни shared runner-и с ограничение от 2000 минути месечно.

Продължени възможности на CI/CD

GitLab CI/CD поддържа ръчно пускане (when: manual), забавено пускане (when: delayed), паралелно изпълнение (parallel: 5), матрица (matrix), динамични pipeline (child pipelines) и многонива pipeline (parent-child). Това позволява изграждане на сложни сценарии: например, динамично генериране на pipeline за всеки модул в монорепозиториум или пускане на паралелни изграждания за различни Android архитектури (arm64, x86_64).

GitLab срещу GitHub: ключови разлики

GitLab и GitHub — двата основни конкурента на пазара на Git платформите, но тяхната философия и архитектура се различават радикално. GitHub залоза на отворената общност, екосистемата от интеграции и социалните функции (форкове, звезди). GitLab се фокусира върху комплексния DevOps цикъл и предоставя всички инструменти извадени от кутията: от планиране до мониторинг.

Основната архитектурна разлика: GitLab — е единно монолитно приложение, което разработчикът инсталира изцяло. Всички функции (CI/CD, Container Registry, Security Scanning, Pages) са вградени и работят веднага след инсталацията. GitHub — е платформа с API, където повечето функции се осъществяват чрез интеграция с услуги на трети страни: Travis CI, CircleCI, Jenkins, SonarQube. Таблицата по-долу сравнява ключовите характеристики:

Изборът между GitLab и GitHub зависи от нуждите на екипа. Ако приоритет е бързо развъртване с нулева конфигурация и отворена общност — изберете GitHub. Ако е необходимо пълно управление на инфраструктурата, собствен хостинг и вградена сигурност — GitLab е предпочитан. Според проучването на Stack Overflow (2024), 90% от разработчиците използват GitHub, 33% — GitLab (често и двете платформи едновременно).

Self-Managed GitLab: инсталация на собствен сървър

Self-Managed GitLab (преди On-Premises) позволява да инсталирате платформата на собствен сървър и да получите пълен контрол над данните, инфраструктурата и достъпността. Това е особено важно за организации с изисквания за съответствие: финансов сектор, държавни институции, медицински организации, където данните не могат да се съхраняват на сървъри на трети страни.

Инсталацията на GitLab се поддържа на Ubuntu, Debian, CentOS и чрез Docker. Официалният Omnibus пакет включва всички компоненти: уеб сървър (NGINX), база данни (PostgreSQL), кеш (Redis), Git процесор (Gitaly) и фонови процеси. Минимални изисквания: 4 GB RAM и 2 CPU за екип до 100 души. За големи инсталации с високо натоварване се препоръчва разделяне на компонентите на отделни сървъри.

# Инсталация на GitLab CE на Ubuntu чрез Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# Инсталация на пакета
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# Преглед на статуса
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab няма ограничения за CI/CD минути — всички runner-и принадлежат на организацията и тяхната мощност е ограничена само от собствения хардуер. Също така са налични Geo-репликация за региони, одитни логове, блокиране на IP и интеграция с корпоративни LDAP/SAML доставчици. GitLab пуска обновления всеки месец (22-ри число) с нови функции и корекции за сигурност.

Вградени инструменти за сигурност на GitLab

Сигурността в GitLab е вградена на ниво платформа и включва няколко скенера, работещи на всеки етап от pipeline. SAST (Static Application Security Testing) анализира изходния код за уязвимости без изпълнение на приложението, поддържайки над 15 езика, включително Java, Kotlin, Swift, Python и JavaScript. DAST (Dynamic Application Security Testing) тества работещото уеб приложение за уязвимости отвътре.

Допълнителни инструменти: Container Scanning проверява Docker образи за уязвимости в основните слоеве; Dependency Scanning анализира зависимостите на проекта и предупреждава за известни CVE; Secret Detection открива случайно комитнати API ключове, пароли и токени; Fuzz Testing изпълнява автоматично тестване с некоректни данни за откриване на неочевидни грешки. Всички резултати от сканирането се показват в единен Security Dashboard.

GitLab също така предоставя Compliance — инструменти за спазване на регулаторните изисквания. Compliance Dashboard показва статуса на съответствието на всички проекти, Audit Events логва всяко действие на администратора и разработчика, а Compliance Frameworks позволяват принудително да се прилагат конфигурационни политики за определени групи проекти. Това прави GitLab популярен избор в корпоративни среди с строги изисквания за сигурност.

Container Registry и Dependency Proxy

GitLab Container Registry — е вграден Docker регистър, интегриран с CI/CD. След изграждане на Docker образ в pipeline, той може да бъде незабавно публикуван в Registry, използвайки променливите на средата CI_REGISTRY и CI_REGISTRY_USER. Registry поддържа pull-through кеширане, етикетиране, политики за почистване и сканиране за уязвимости директно в регистъра.

Dependency Proxy — механизъм за кеширане на контейнери и образи от външни регистъри (Docker Hub, Quay, GCR). Когато pipeline поиска образ ubuntu:latest, GitLab първо проверява собствения си кеш — ако образът вече е зареден, той не се изтегля отново. Това намалява натоварването на външните регистъри, ускорява pipeline-ите и предпазва от лимитите на скоростта на Docker Hub.

За мобилни разработчици GitLab предоставя GitLab Pages за хостване на документация и тестови отчети. След изпълняване на тестовете, артефактите (HTML отчети, екранни снимки, логове) могат да бъдат публикувани като Pages и да получат връзка за изпращане на QA екипа. Това е по-удобно от качване на отчети в облачно хранилище, тъй като всичко се поставя в рамките на същия GitLab проект.

GitLab API и Webhooks

GitLab API (REST и GraphQL) предоставя достъп до всички ресурси на платформата: проекти, потребители, pipeline-и, Merge Request, регистър. API се използва за автоматизация: създаване на проект от шаблон, назначаване на рецензент, получаване на статус на pipeline. Webhooks позволяват изпращане на HTTP уведомления до външни системи при събития: push, merge, създаване на Issue. Webhooks се интегрират с Mattermost, Slack, Telegram и вътрешни мониторингови системи.

GitLab Pages за мобилна документация

GitLab Pages автоматично публикува статични уебсайтове от репозиториума. За мобилни проекти Pages са удобни за размещане на API документация, отчети за покритие на тестовете и резултати от lint анализ. Публикуването става автоматично след успешен pipeline — достатъчно е да посочите в .gitlab-ci.yml deploy стъпка с публикуване в Pages. Резултатът е достъпен на адрес https://namespace.gitlab.io/ime-proekt.