GitLab CI: ماهیت، پایپ‌لاین‌ها و یکپارچه‌سازی مداوم

GitLab CI چیست؟

GitLab CI بخشی از اپلیکیشن یکپارچه DevSecOps گیت‌لب است که یکپارچه‌سازی، تحویل و استقرار مداوم را شامل می‌شود. این سیستم در سال ۲۰۱۲ به عنوان یک پروژه جداگانه ظاهر شد، اما سپس مستقیماً در GitLab ادغام شد. اصل اصلی — پیکربندی به عنوان کد (Configuration as Code) از طریق فایل .gitlab-ci.yml در ریشه مخزن. GitLab CI هم در نسخه ابری SaaS و هم در نصب self-managed در دسترس است.

برای توسعه موبایل، GitLab CI خودکارسازی ساخت APK و IPA، اجرای تست‌های ابزاری، تحلیل ایستای کد، امضای اپلیکیشن‌ها و انتشار در فروشگاه‌ها را ارائه می‌دهد. پلتفرم از تصاویر Docker برای محیط‌های سفارشی پشتیبانی می‌کند که امکان نصب از پیش Android SDK، NDK، Xcode و سایر ابزارها را فراهم می‌کند. Container Registry داخلی ذخیره و توزیع تصاویر را در تیم ساده‌تر می‌کند.

معماری GitLab CI: Runners، Pipelines و Stages

معماری GitLab CI از سه مؤلفه کلیدی تشکیل شده است. GitLab Runner عاملی است که jobs را اجرا می‌کند. Runners به سه نوع shared (ارائه شده توسط GitLab)، group (برای گروه پروژه‌ها) و specific (برای یک پروژه) تقسیم می‌شوند. هر runner با تعیین executor ثبت می‌شود: Shell، Docker، Kubernetes یا VirtualBox. GitLab Runner از خودکار‌‌مقیاس‌سازی (auto-scaling) برای مدیریت بارهای اوج پشتیبانی می‌کند.

Pipeline مجموعه‌ای از stages است که به صورت ترتیبی اجرا می‌شوند. در داخل یک stage، jobs به صورت موازی اجرا می‌شوند. ساختار معمولی برای پروژه موبایل: build → test → deploy. اگر job در stage test با خطا پایان یابد، deploy اجرا نمی‌شود. می‌توان اجرای دستی (when: manual) را برای استقرار پیکربندی کرد. همچنین triggerهای multi-project pipelines برای سناریوهای پیچیده CI/CD بین مخازن پشتیبانی می‌شود.

Executorهای GitLab Runner

Docker executor — محبوب‌ترین برای CI/CD اپلیکیشن‌های موبایل. هر job در یک کانتینر Docker تمیز اجرا می‌شود که ایزوله بودن و تکرارپذیری را تضمین می‌کند. برای ساخت Android از تصویر android-sdk با SDK از پیش نصب شده استفاده می‌شود، برای iOS — macOS runner با Shell executor.

پیکربندی .gitlab-ci.yml برای پروژه‌های موبایل

فایل .gitlab-ci.yml خط لوله را در قالب YAML تعریف می‌کند. بخش‌های اصلی: image (تصویر Docker)، stages (لیست مراحل)، variables (متغیرهای محیطی)، before_script (دستورات قبل از هر job) و خود jobs با بخش‌های script، artifacts، cache. GitLab CI از include پشتیبانی می‌کند — اتصال فایل‌های YAML خارجی برای استفاده مجدد از پیکربندی‌های مشترک بین پروژه‌ها.

متغیرها در GitLab CI می‌توانند در چندین سطح تنظیم شوند: سراسری در UI، در فایل پیکربندی، در تنظیمات گروه و پروژه. اولویت متغیرها توسط سلسله‌مراتب تعیین می‌شود: trigger variables بالاترین اولویت را دارند، سپس CI/CD variables از UI، سپس از .gitlab-ci.yml. متغیرها می‌توانند محافظت شوند (protected) که آنها را فقط برای branchها و tagهای محافظت شده قابل دسترس می‌کند.

متغیرهای پایه و تصویر

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/

ساخت job با artifactها

job generate-apk پروژه Gradle را می‌سازد و APK را به عنوان artifact ذخیره می‌کند. Artifactها بین stages منتقل می‌شوند — job deploy می‌تواند از APK ساخته شده استفاده کند. مدت زمان نگهداری artifactها از طریق expire_in پیکربندی می‌شود.

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

GitLab CI در مقابل GitHub Actions: تفاوت‌های کلیدی

در انتخاب بین GitLab CI و GitHub Actions برای پروژه موبایل، در نظر گرفتن زیرساخت تیم مهم است. GitLab CI یک Container Registry داخلی ارائه می‌دهد که می‌توان از آن برای ذخیره تصاویر Docker با Android SDK استفاده کرد. GitHub Actions به GitHub Packages یا رجیستری‌های خارجی متکی است. GitLab همچنین دارای SAST داخلی (آزمون امنیتی ایستای برنامه) برای تحلیل کد از نظر آسیب‌پذیری‌ها است.

GitLab CI مدل runner انعطاف‌پذیرتری ارائه می‌دهد — از Kubernetes executor، auto-scaling و تصاویر سفارشی پشتیبانی می‌کند. GitHub Actions در ادغام با اکوسیستم GitHub و بازار actions برنده است. GitLab CI نیاز به پیکربندی دستی برای بسیاری از وظایفی دارد که در GitHub Actions با یک action آماده حل می‌شوند.

از دیدگاه CI/CD برای پروژه‌های موبایل: GitLab CI برای شرکت‌هایی که از GitLab Self-Managed استفاده می‌کنند و به runners خودمیزبان با Docker/Kubernetes نیاز دارند مناسب‌تر است. GitHub Actions برای تیم‌های کوچکی که از GitHub ابری استفاده می‌کنند و برای actions آماده و سادگی پیکربندی ارزش قائل هستند راحت‌تر است.

مقایسه قابلیت‌ها

مثال پایپ‌لاین برای پروژه Android

پایپ‌لاین کامل برای Android شامل: lint، تست واحد، ساخت و استقرار در Firebase App Distribution. پایپ‌لاین از تصویر Docker با Android SDK، ذخیره‌سازی کش Gradle و اجرای موازی lint و تست در یک stage استفاده می‌کند. این رویکرد زمان کل پایپ‌لاین را کاهش می‌دهد، زیرا وظایف lint و تست به یکدیگر وابسته نیستند.

برای پروژه‌های iOS ساختار پایپ‌لاین به دلیل نیاز به macOS runner و امضای کد متفاوت است. پایپ‌لاین iOS معمولی شامل: نصب CocoaPods یا SPM، اجرای تست‌ها روی شبیه‌ساز، بایگانی پروژه Xcode، استخراج IPA و بارگذاری در TestFlight. GitLab CI برای iOS از macOS runners استفاده می‌کند — یا GitLab SaaS macOS runners با محدودیت زمانی، یا self-hosted runner روی Mac mini یا MacStadium.

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

بهینه‌سازی پایپ‌لاین‌های ساخت موبایل در GitLab CI نیاز به توجه به جزئیات دارد. پیکربندی صحیح cache و artifacts امکان کاهش زمان ساخت را چندین برابر فراهم می‌کند. برای تحلیل عملکرد، GitLab CI/CD Analytics را ارائه می‌دهد — داشبوردی با معیارهای مدت زمان پایپ‌لاین‌ها، بار runners و تنگناها. این معیارها را به طور منظم برای یافتن فرصت‌های بهینه‌سازی تحلیل کنید. تنظیم resource_group اجرای موازی یک پایپ‌لاین را مسدود می‌کند — این برای جلوگیری از تداخل‌ها هنگام استقرار مفید است.

استراتژی شاخه‌ها برای CI نیز مهم است. توصیه می‌شود پایپ‌لاین کامل را فقط برای شاخه‌های main و release اجرا کنید و برای شاخه‌های feature — فقط lint و تست‌های واحد. این کار دقایق runners را ذخیره می‌کند و بازخورد را به توسعه‌دهندگان سرعت می‌بخشد. GitLab CI از workflow:rules پشتیبانی می‌کند — قوانین شرطی برای شامل یا حذف کردن jobs بسته به شاخه، فایل‌های تغییر یافته یا متغیرهای محیطی.

ذخیره‌سازی کش وابستگی‌ها — راه اصلی سرعت‌بخشی. GitLab CI .gradle، Pods و node_modules را بین اجراها کش می‌کند. کلید کش شامل $CI_COMMIT_REF_SLUG یا هش فایل lock است. زمان ساخت پروژه Android با کش صحیح از ۱۰–۱۵ به ۲–۴ دقیقه کاهش می‌یابد. کش می‌تواند توزیع‌شده باشد — GitLab از cache:key با fallback به کلیدهای قبلی پشتیبانی می‌کند.

تصویر Docker با ابزارهای از پیش نصب شده در وقت نصب صرفه‌جویی می‌کند. توصیه می‌شود یک تصویر سفارشی با Android SDK، NDK و سطح API مورد نیاز ایجاد کنید. اجرای موازی jobs (lint، test، assemble) در stages مختلف زمان کل پایپ‌لاین را کاهش می‌دهد. Pull policies برای تصاویر (if-not-present) شروع jobs را سرعت می‌بخشد. همچنین می‌توان از dependency proxy برای کش کردن تصاویر در سطح نمونه GitLab استفاده کرد.

جنبه مهم دیگر بهینه‌سازی — استفاده از artifactها بین مراحل است. فایل‌های حجیم APK و IPA بهتر است از طریق dependency منتقل شوند تا اینکه در هر job دوباره ساخته شوند. برای پروژه‌های بزرگ با ده‌ها ماژول، توصیه می‌شود Gradle Build Cache را در سطح پایپ‌لاین فعال کنید و remote cache را در یک انبار مشترک پیکربندی کنید. Timeout برای هر job باید بر اساس زمان ساخت مورد انتظار تنظیم شود — این کار از فرآیندهای قفل شده جلوگیری می‌کند.

مثال با کش و pull policy

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

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