GitLab — mga batayan, kakayahan at CI/CD

Ano ang GitLab?

GitLab — ay isang ganap na DevOps platform na may open source sa ilalim ng MIT license. Hindi tulad ng GitHub na pinagsasama ang iba't ibang serbisyo sa pamamagitan ng integrations, ang GitLab ay nagbibigay ng iisang tool para sa buong lifecycle ng development: mula sa code management at code review hanggang CI/CD, monitoring, seguridad at deployment. Ang platform ay hindi nangangailangan ng third-party na serbisyo para sa karamihan ng mga gawaing DevOps.

Ang kasaysayan ng GitLab ay nagsimula noong 2011 bilang isang internal na proyekto ng mga Ukrainian developer. Ang unang pampublikong bersyon ay inilabas noong Setyembre 2011, at noong 2015 ang GitLab ay naging unang proyekto sa GitLab.com, na naglunsad ng cloud hosting. Noong 2017, GitLab ay nagsagawa ng masakit ngunit nakapagpapaliwanag na proseso ng migration — ang paglipat ng buong imprastraktura mula Azure patungong Google Cloud, na na-broadcast nang live at na-dokumento sa isang serye ng mga post.

Ang arkitektura ng GitLab ay binubuo ng tatlong pangunahing bahagi: GitLab Rails (web application sa Ruby on Rails), GitLab Shell (pagproseso ng mga Git operation sa pamamagitan ng SSH) at Gitaly (gRPC server para sa pag-access sa Git data). Ang CI/CD ay ibinibigay sa pamamagitan ng GitLab Runner — isang hiwalay na application na naka-install sa build server at nagpapatakbo ng mga job sa isolated na environment (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: mga pipeline at runner

GitLab CI/CD — ay isang built-in na continuous integration at delivery system, na isang pangunahing bentahe ng platform. Hindi tulad ng GitHub Actions, ang GitLab CI/CD ay isinama sa arkitektura mula pa sa simula at hindi nangangailangan ng hiwalay na configuration: bawat proyekto ay awtomatikong nakakakuha ng CI/CD pagkatapos idagdag ang file na .gitlab-ci.yml sa root ng repository.

Ang pipeline (pipeline) ay binubuo ng mga yugto (stages) na isinasagawa nang sunud-sunod o parallel: build → test → deploy. Bawat yugto ay naglalaman ng isa o higit pang job na isinasagawa sa mga runner. Kung ang isang job sa yugto ay nagtapos sa error, ang buong yugto ay minarkahan bilang failed, at ang mga susunod na yugto ay hindi isinasagawa bilang default. Sa ibaba ay isang halimbawa ng pipeline para sa isang 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

Ang GitLab Runner ay sumusuporta sa maraming executor (tagapagpatupad): Docker (inirerekomenda), Kubernetes, SSH, VirtualBox at Parallels. Ang pinakasikat na opsyon ay ang Docker executor, na nagpapatakbo ng bawat job sa isang hiwalay na container. Ang runner ay maaaring irehistro bilang spesipiko para sa isang proyekto o bilang shared para sa buong grupo. Ang GitLab.com ay nagbibigay ng libreng shared runner na may limitasyong 2000 minuto bawat buwan.

Mga Advanced na Kakayahang CI/CD

GitLab CI/CD ay sumusuporta sa manual na pagpapatakbo (when: manual), delay na pagpapatakbo (when: delayed), parallel na pagpapatupad (parallel: 5), matrix, dynamic na pipeline (child pipelines) at multi-level na pipeline (parent-child). Ito ay nagbibigay-daan sa pagbuo ng mga kumplikadong scenario: halimbawa, dynamic na pag-generate ng pipeline para sa bawat module sa monorepository o pagpapatakbo ng parallel builds para sa iba't ibang Android architecture (arm64, x86_64).

GitLab laban sa GitHub: mga pangunahing pagkakaiba

GitLab at GitHub — dalawang pangunahing kakumpitensya sa merkado ng Git platforms, ngunit ang kanilang pilosopiya at arkitektura ay fundamental na naiiba. Ang GitHub ay nakatuon sa bukas na komunidad, ecosystem ng integrations at social features (forks, bituin). Ang GitLab ay nakatuon sa komprehensibong DevOps cycle at nagbibigay ng lahat ng tool na handa na: mula sa pagpaplano hanggang sa monitoring.

Pangunahing pagkakaiba sa arkitektura: GitLab — ay isang monolitikong application na ini-install ng developer nang buo. Lahat ng features (CI/CD, Container Registry, Security Scanning, Pages) ay built-in at gumagana kaagad pagkatapos ng installation. GitHub — ay isang platform na may API, kung saan ang karamihan ng features ay ipinatutupad sa pamamagitan ng integration sa third-party na serbisyo: Travis CI, CircleCI, Jenkins, SonarQube. Ang talahanayan sa ibaba ay naghahambing ng mga pangunahing katangian:

Ang pagpili sa pagitan ng GitLab at GitHub ay depende sa pangangailangan ng team. Kung ang priority ay mabilis na deployment na may zero configuration at bukas na komunidad — piliin ang GitHub. Kung kailangan ang buong kontrol sa imprastraktura, sariling hosting at built-in na seguridad — mas gusto ang GitLab. Ayon sa Stack Overflow survey (2024), 90% ng mga developer ay gumagamit ng GitHub, 33% — GitLab (madalas parehong platform nang sabay).

Self-Managed GitLab: pag-install sa sariling server

Self-Managed GitLab (dating On-Premises) ay nagbibigay-daan sa pag-install ng platform sa sariling server at magkaroon ng buong kontrol sa data, imprastraktura at availability. Ito ay lalong mahalaga para sa mga organisasyon na may compliance requirements: financial sector, mga ahensya ng gobyerno, mga medikal na organisasyon, kung saan ang data ay hindi maiimbak sa third-party na server.

Ang pag-install ng GitLab ay suportado sa Ubuntu, Debian, CentOS at sa pamamagitan ng Docker. Ang opisyal na Omnibus package ay may kasamang lahat ng component: web server (NGINX), database (PostgreSQL), cache (Redis), Git processor (Gitaly) at background processes. Minimum na requirements: 4 GB RAM at 2 CPU para sa team na hanggang 100 tao. Para sa malalaking installation na may mataas na load, inirerekomenda ang paghihiwalay ng mga component sa magkakahiwalay na server.

# Pag-install ng GitLab CE sa Ubuntu sa pamamagitan ng Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

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

# Pagtingin ng status
sudo gitlab-ctl status
sudo gitlab-ctl tail

Ang Self-Managed GitLab ay walang limitasyon sa CI/CD minutes — lahat ng runner ay pag-aari ng organisasyon, at ang kanilang kapangyarihan ay limitado lamang ng sariling hardware. Gayundin, available ang Geo-replication para sa mga rehiyon, audit logs, IP blocking at integration sa corporate LDAP/SAML provider. Ang GitLab ay naglalabas ng updates bawat buwan (ika-22) na may mga bagong feature at security fixes.

Mga built-in na tool sa seguridad ng GitLab

Seguridad sa GitLab ay built-in sa antas ng platform at may kasamang maraming scanner na gumagana sa bawat yugto ng pipeline. SAST (Static Application Security Testing) ay sumusuri ng source code para sa mga vulnerability nang hindi pinapatakbo ang application, sumusuporta sa higit 15 wika, kabilang ang Java, Kotlin, Swift, Python at JavaScript. DAST (Dynamic Application Security Testing) ay sumusubok ng tumatakbong web application para sa mga vulnerability mula sa loob.

Mga karagdagang tool: Container Scanning ay sumusuri ng Docker images para sa mga vulnerability sa base layers; Dependency Scanning ay sumusuri ng project dependencies at nagbababala tungkol sa mga kilalang CVE; Secret Detection ay nakakahanap ng aksidenteng na-commit na API keys, password at tokens; Fuzz Testing ay nagsasagawa ng automated testing na may maling data para makahanap ng hindi halatang bugs. Lahat ng scan results ay ipinapakita sa iisang Security Dashboard.

Nagbibigay din ang GitLab ng Compliance — mga tool para sa pagsunod sa regulatory requirements. Ang Compliance Dashboard ay nagpapakita ng compliance status ng lahat ng proyekto, Audit Events ay nagla-log ng bawat aksyon ng administrator at developer, at Compliance Frameworks ay nagbibigay-daan sa sapilitang pagpapatupad ng configuration policies para sa partikular na grupo ng proyekto. Ito ay ginagawang popular na pagpipilian ang GitLab sa corporate na environment na may mahigpit na requirements sa seguridad.

Container Registry at Dependency Proxy

GitLab Container Registry — ay isang built-in na Docker registry na integrated sa CI/CD. Pagkatapos bumuo ng Docker image sa pipeline, maaari itong agad na i-publish sa Registry gamit ang environment variables na CI_REGISTRY at CI_REGISTRY_USER. Ang Registry ay sumusuporta sa pull-through caching, tagging, clean-up policies at vulnerability scanning nang direkta sa registry.

Dependency Proxy — mekanismo para sa pag-cache ng mga container at image mula sa external registries (Docker Hub, Quay, GCR). Kapag ang pipeline ay humiling ng image na ubuntu:latest, unang titingnan ng GitLab ang sarili nitong cache — kung ang image ay na-load na, hindi ito dina-download muli. Ito ay nagbabawas ng load sa external registries, nagpapabilis ng pipeline at nagpoprotekta laban sa rate limits ng Docker Hub.

Para sa mga mobile developer, nagbibigay ang GitLab ng GitLab Pages para sa pagho-host ng documentation at test reports. Pagkatapos patakbuhin ang mga test, ang artifacts (HTML reports, screenshots, logs) ay maaaring i-publish bilang Pages at makakuha ng link para ipadala sa QA team. Ito ay mas maginhawa kaysa mag-upload ng reports sa cloud storage, dahil lahat ay inilalagay sa loob ng parehong GitLab project.

GitLab API at Webhooks

GitLab API (REST at GraphQL) ay nagbibigay ng access sa lahat ng resources ng platform: projects, users, pipelines, Merge Request, registry. Ang API ay ginagamit para sa automation: gumawa ng project mula sa template, mag-assign ng reviewer, makuha ang pipeline status. Webhooks ay nagbibigay-daan sa pagpapadala ng HTTP notifications sa external systems sa mga events: push, merge, paggawa ng Issue. Ang Webhooks ay nag-i-integrate sa Mattermost, Slack, Telegram at internal monitoring systems.

GitLab Pages para sa Mobile Documentation

GitLab Pages ay awtomatikong nagpo-publish ng static websites mula sa repository. Para sa mobile projects, ang Pages ay kapaki-pakinabang para sa paglalagay ng API documentation, test coverage reports at lint analysis results. Ang pag-publish ay awtomatikong nangyayari pagkatapos ng matagumpay na pipeline — sapat na itakda ang deploy step na may publication sa Pages sa .gitlab-ci.yml. Ang resulta ay available sa https://namespace.gitlab.io/project-name.