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-и и ранери

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

Pipeline (pipeline) се састоји од фаза (stages) које се извршавају секвенцијално или паралелно: build → test → deploy. Свака фаза садржи један или више job-ова који се извршавају на ранерима. Ако се један 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 ранере са ограничењем од 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)., GitHub користи 90% програмера, GitLab — 33% (често обе платформе истовремено).

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 у минутама — сви ранери припадају организацији, а њихова снага је ограничена само сопственим хардвером. Такође су доступни 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 и Webhook-ови

GitLab API (REST и GraphQL) пружа приступ свим ресурсима платформе: пројекти, корисници, pipeline-и, Merge Request, регистар. API се користи за аутоматизацију: креирање пројекта из шаблона, додељивање рецензента, добијање статуса pipeline-а. Webhook-ови омогућавају слање HTTP обавештења у спољне системе при догађајима: push, merge, креирање Issue-а. Webhook-ови се интегришу са Mattermost, Slack, Telegram и унутрашњим системима за мониторинг.

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

GitLab Pages аутоматски објављује статичке веб сајтове из репозиторијума. За мобилне пројекте, Pages је погодан за постављање API документације, извештаја о покривености тестова и резултата lint анализе. Објављивање се дешава аутоматски након успешног pipeline-а — довољно је навести у .gitlab-ci.yml deploy корак са објављивањем у Pages. Резултат је доступан на адреси https://namespace.gitlab.io/ime-projekta.