GitLab CI: mohiyati, pipeline’lar va uzluksiz integratsiya

GitLab CI nima?

GitLab CI — bu GitLab yagona DevSecOps ilovasining uzluksiz integratsiya, yetkazib berish va joylashtirishni o‘z ichiga olgan qismidir. Tizim 2012 yilda alohida loyiha sifatida paydo bo‘ldi, ammo keyin to‘g‘ridan-to‘g‘ri GitLab-ga integratsiya qilindi. Asosiy printsip — konfiguratsiyani kod sifatida (Configuration as Code) repozitoriyning ildizidagi .gitlab-ci.yml fayli orqali amalga oshirish. GitLab CI ham bulutli SaaS versiyasida, ham self-managed o‘rnatishda mavjud.

Mobil ishlanma uchun GitLab CI APK va IPA qurilishini avtomatlashtirish, instrumental testlarni ishga tushirish, statik kod tahlili, ilovalarni imzolash va do‘konlarda nashr qilishni taklif etadi. Platforma maxsus muhitlar uchun Docker tasvirlarini qo‘llab-quvvatlaydi, bu Android SDK, NDK, Xcode va boshqa vositalarni oldindan o‘rnatish imkonini beradi. O‘rnatilgan Container Registry jamoa ichida tasvirlarni saqlash va tarqatishni osonlashtiradi.

GitLab CI Arxitekturasi: Runnerlar, Pipelinelar va Stages

GitLab CI arxitekturasi uchta asosiy komponentdan iborat. GitLab Runner — ishlarni bajaruvchi agent. Runnerlar shared (GitLab tomonidan taqdim etiladi), group (loyihalar guruhi uchun) va specific (bitta loyiha uchun) bo‘lishi mumkin. Har bir runner executor ko‘rsatilgan holda ro‘yxatdan o‘tadi: Shell, Docker, Kubernetes yoki VirtualBox. GitLab Runner cho‘qqi yuklamalarni qayta ishlash uchun avtomatik masshtablashni (auto-scaling) qo‘llab-quvvatlaydi.

Pipeline — ketma-ket bajariladigan stages to‘plami. Bitta stage ichida ishlar parallel bajariladi. Mobil loyiha uchun odatiy tuzilma: build → test → deploy. Agar test stage’idagi ish xato bilan tugasa, deploy ishga tushirilmaydi. Joylashtirish uchun qo‘lda ishga tushirish (when: manual) sozlanishi mumkin. Shuningdek, repozitoriyalar o‘rtasida murakkab CI/CD stsenariylari uchun multi-project pipelines triggerlari qo‘llab-quvvatlanadi.

GitLab Runner Executorlari

Docker executor — mobil ilovalar CI/CD si uchun eng mashhur. Har bir ish toza Docker konteynerida ishga tushiriladi, bu izolyatsiya va takrorlanuvchanlikni kafolatlaydi. Android qurilishi uchun oldindan o‘rnatilgan SDK bilan android-sdk tasviri ishlatiladi, iOS uchun — Shell executor bilan macOS runner.

Mobil Loyihalar Uchun .gitlab-ci.yml Konfiguratsiyasi

.gitlab-ci.yml fayli pipeline’ni YAML formatida belgilaydi. Asosiy bo‘limlar: image (Docker tasviri), stages (bosqichlar ro‘yxati), variables (muhit o‘zgaruvchilari), before_script (har bir ishdan oldingi buyruqlar) va script, artifacts, cache bo‘limlari bilan ishlarning o‘zi. GitLab CI include ni qo‘llab-quvvatlaydi — loyihalar o‘rtasida umumiy konfiguratsiyalarni qayta ishlatish uchun tashqi YAML fayllarini ulash.

GitLab CI-da o‘zgaruvchilar bir necha darajada o‘rnatilishi mumkin: UI-da global, konfiguratsiya faylida, guruh va loyiha sozlamalarida. O‘zgaruvchilar ustuvorligi iyerarxiya bilan belgilanadi: trigger variables eng yuqori ustuvorlikka ega, keyin UI-dan CI/CD variables, keyin .gitlab-ci.yml dan. O‘zgaruvchilar himoyalanishi mumkin (protected), bu ularni faqat himoyalangan branch va tag’lar uchun mavjud qiladi.

Asosiy o‘zgaruvchilar va tasvir

image: openjdk:17-jdk-slim

variables:
  ANDROID_SDK_VERSION: "35"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test
  - deploy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/

Artefaktlar bilan qurish ishi

generate-apk ishi Gradle loyihasini quradi va APK ni artefakt sifatida saqlaydi. Artefaktlar stages o‘rtasida uzatiladi — deploy ishi build dan APK dan foydalanishi mumkin. Artefaktlarning saqlash muddati expire_in orqali sozlanadi.

generate-apk:
  stage: build
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release/
    expire_in: 1 day

GitLab CI vs GitHub Actions: Asosiy Farqlar

Mobil loyiha uchun GitLab CI va GitHub Actions o‘rtasida tanlashda jamoaning infratuzilmasini hisobga olish muhim. GitLab CI Android SDK bilan Docker tasvirlarini saqlash uchun ishlatilishi mumkin bo‘lgan o‘rnatilgan Container Registry ni taqdim etadi. GitHub Actions GitHub Packages yoki tashqi registrlarga tayanadi. GitLab shuningdek, zaifliklar uchun kod tahlili uchun o‘rnatilgan SAST (Static Application Security Testing) ga ega.

GitLab CI yanada moslashuvchan runner modelini taklif etadi — Kubernetes executor, avtomatik masshtablash va maxsus tasvirlarni qo‘llab-quvvatlaydi. GitHub Actions GitHub ekotizimi va actions bozori bilan integratsiyada g‘alaba qozonadi. GitLab CI GitHub Actions-da tayyor action bilan hal qilinadigan ko‘plab vazifalar uchun qo‘lda konfiguratsiyani talab qiladi.

Mobil loyihalar uchun CI/CD nuqtayi nazaridan: GitLab CI allaqachon GitLab Self-Managed dan foydalanadigan va Docker/Kubernetes bilan self-hosted runnerlarni talab qiladigan kompaniyalar uchun ko‘proq mos keladi. GitHub Actions bulutli GitHub-dan foydalanadigan, tayyor actions va sozlash qulayligini qadrlaydigan kichik jamoalar uchun qulayroq.

Imkoniyatlarni taqqoslash

Android Loyihasi Uchun Pipeline Namunasi

Android uchun to‘liq pipeline o‘z ichiga oladi: lint, birlik testlari, qurish va Firebase App Distribution da joylashtirish. Pipeline Android SDK bilan Docker tasviri, Gradle keshilashi va bir stage ichida lint va testlarning parallel bajarilishidan foydalanadi. Bunday yondashuv pipeline’ning umumiy vaqtini qisqartiradi, chunki lint va test vazifalari bir-biriga bog‘liq emas.

iOS loyihalari uchun pipeline tuzilmasi macOS runner va kod imzolash zarurati tufayli farq qiladi. Odatiy iOS pipeline’i o‘z ichiga oladi: CocoaPods yoki SPM o‘rnatish, simulyatorda testlarni ishga tushirish, Xcode loyihasini arxivlash, IPA eksporti va TestFlight ga yuklash. iOS uchun GitLab CI macOS runnerlardan foydalanadi — yoki vaqt cheklovlari bilan GitLab SaaS macOS runnerlari, yoki Mac mini yoki MacStadium da self-hosted runner.

image: androidsdk/android-35:latest

stages:
  - lint
  - test
  - build
  - deploy

lint-check:
  stage: lint
  script: ./gradlew lint

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

assemble-release:
  stage: build
  script: ./gradlew assembleRelease
  artifacts:
    paths: [app/build/outputs/apk/release/]

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute
    --app $FIREBASE_APP_ID
    --token $FIREBASE_TOKEN
    --groups testers

GitLab CI-da Qurilish Vaqtini Optimallashtirish

GitLab CI-da mobil qurish pipelinelarini optimallashtirish tafsilotlarga e’tibor talab qiladi. Cache va artifacts ni to‘g‘ri sozlash qurish vaqtini bir necha marta kamaytirishga imkon beradi. Ishlash tahlili uchun GitLab CI/CD Analytics ni taqdim etadi — pipeline davomiyligi, runner yuklamasi va tor joylar ko‘rsatkichlari bilan panel. Optimallashtirish imkoniyatlarini topish uchun ushbu ko‘rsatkichlarni muntazam tahlil qiling. resource_group sozlamasi bitta pipeline’ning parallel ishga tushirilishini bloklaydi — bu joylashtirish paytida nizolarni oldini olish uchun foydali.

CI uchun branch strategiyasi ham muhim. To‘liq pipeline’ni faqat main va release branch’lar uchun ishga tushirish, feature branch’lar uchun esa faqat lint va birlik testlari tavsiya etiladi. Bu runner daqiqalarini tejaydi va dasturchilarga fikr-mulohazani tezlashtiradi. GitLab CI workflow:rules ni qo‘llab-quvvatlaydi — branch, o‘zgartirilgan fayllar yoki muhit o‘zgaruvchilariga qarab ishlarni kiritish yoki chiqarish uchun shartli qoidalar.

Bog‘liqliklarni keshilash — tezlashtirishning asosiy usuli. GitLab CI ishga tushirishlar o‘rtasida .gradle, Pods va node_modules ni keshilaydi. Kesh kaliti $CI_COMMIT_REF_SLUG yoki lock faylining heshini o‘z ichiga oladi. Android loyihasining qurish vaqti to‘g‘ri keshilash bilan 10–15 dan 2–4 daqiqagacha qisqaradi. Kesh taqsimlangan bo‘lishi mumkin — GitLab oldingi kalitlarga fallback bilan cache:key ni qo‘llab-quvvatlaydi.

Oldindan o‘rnatilgan vositalar bilan Docker tasviri o‘rnatish vaqtini tejaydi. Android SDK, NDK va kerakli API darajasi bilan maxsus tasvir yaratish tavsiya etiladi. Turli stage’larda ishlarning (lint, test, assemble) parallel bajarilishi pipeline’ning umumiy vaqtini qisqartiradi. Tasvirlar uchun pull policy (if-not-present) ishlarning boshlanishini tezlashtiradi. Shuningdek, GitLab instance darajasida tasvirlarni keshilash uchun dependency proxy dan foydalanish mumkin.

Optimallashtirishning yana bir muhim jihati — bosqichlar o‘rtasida artefaktlardan foydalanish. Og‘ir fayllar APK va IPA ni har bir ishda qayta qurish o‘rniga dependency orqali uzatish yaxshiroq. O‘nlab modulli katta loyihalar uchun pipeline darajasida Gradle Build Cache ni yoqish va umumiy omborda remote cache sozlash tavsiya etiladi. Har bir ish uchun timeout kutilgan qurish vaqtiga qarab o‘rnatilishi kerak — bu osilgan jarayonlarning oldini oladi.

Keshilash va pull policy bilan namuna

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/
    - app/build/

image:
  name: registry.example.com/android-builder:3.5
  pull_policy: if-not-present