GitLab CI: پائپ لائنز اور مسلسل انضمام

GitLab CI کیا ہے؟

GitLab CI متحد DevSecOps GitLab ایپلیکیشن کا حصہ ہے، جس میں مسلسل انضمام، ترسیل اور تعیناتی شامل ہے۔ یہ نظام 2012 میں ایک علیحدہ پروجیکٹ کے طور پر شروع ہوا لیکن بعد میں براہ راست GitLab میں ضم ہو گیا۔ بنیادی اصول کوڈ کے طور پر کنفیگریشن ہے جو ریپوزٹری روٹ میں .gitlab-ci.yml فائل کے ذریعے ہوتی ہے۔ GitLab CI کلاؤڈ SaaS ورژن اور خود انتظامی تنصیب دونوں میں دستیاب ہے۔

موبائل ڈویلپمنٹ کے لیے، GitLab CI APK اور IPA بلڈز کی آٹومیشن، آلہ شدہ ٹیسٹ چلانے، جامد کوڈ تجزیہ، ایپ دستخط اور اسٹور پر اشاعت فراہم کرتا ہے۔ پلیٹ فارم حسب ضرورت ماحول کے لیے Docker امیجز کو سپورٹ کرتا ہے، جس سے Android SDK، NDK، Xcode اور دیگر ٹولز پہلے سے انسٹال کیے جا سکتے ہیں۔ بلٹ ان Container Registry ٹیم کے اندر امیجز کی ذخیرہ اندوزی اور تقسیم کو آسان بناتا ہے۔

GitLab CI کا فن تعمیر: Runners، Pipelines اور Stages

GitLab CI کا فن تعمیر تین اہم اجزاء پر مشتمل ہے۔ GitLab Runner ایک ایجنٹ ہے جو کاموں کو انجام دیتا ہے۔ رنرز مشترکہ (GitLab کے ذریعہ فراہم کردہ)، گروپ (پروجیکٹس کے گروپ کے لیے) یا مخصوص (ایک پروجیکٹ کے لیے) ہو سکتے ہیں۔ ہر رنر ایک ایکزیکیوٹر کے ساتھ رجسٹر ہوتا ہے: Shell، Docker، Kubernetes یا VirtualBox۔ GitLab Runner چوٹی کے بوجھ کو سنبھالنے کے لیے خودکار پیمائش (آٹو اسکیلنگ) کو سپورٹ کرتا ہے۔

پائپ لائن ترتیب وار انجام دیے جانے والے سٹیجز کا ایک مجموعہ ہے۔ ایک سٹیج کے اندر، کام متوازی طور پر چلتے ہیں۔ موبائل پروجیکٹ کے لیے ایک عام ڈھانچہ ہے: build → test → deploy۔ اگر test سٹیج پر کوئی کام ناکام ہوتا ہے تو deploy متحرک نہیں ہوتا۔ تعیناتی کے لیے دستی ٹرگر (when: manual) ترتیب دیا جا سکتا ہے۔ ریپوزٹریوں کے درمیان پیچیدہ CI/CD منظرناموں کے لیے ملٹی پروجیکٹ پائپ لائن ٹرگرز بھی سپورٹ کیے جاتے ہیں۔

GitLab Runner کے ایکزیکیوٹرز

Docker ایکزیکیوٹر موبائل ایپ CI/CD کے لیے سب سے مقبول ہے۔ ہر کام ایک صاف Docker کنٹینر میں چلتا ہے، جو تنہائی اور تولیدی صلاحیت کو یقینی بناتا ہے۔ Android بلڈز کے لیے پہلے سے انسٹال SDK والی android-sdk امیج استعمال ہوتی ہے؛ iOS کے لیے Shell ایکزیکیوٹر والا macOS رنر استعمال ہوتا ہے۔

موبائل پروجیکٹس کے لیے .gitlab-ci.yml کنفیگریشن

.gitlab-ci.yml فائل YAML فارمیٹ میں پائپ لائن کی وضاحت کرتی ہے۔ اہم حصے شامل ہیں: image (Docker امیج)، stages (سٹیجز کی فہرست)، variables (ماحولی متغیرات)، before_script (ہر کام سے پہلے کمانڈز) اور script، artifacts، cache حصوں والے کام۔ GitLab CI include کو سپورٹ کرتا ہے — پروجیکٹس کے درمیان مشترکہ کنفیگریشنز کو دوبارہ استعمال کرنے کے لیے بیرونی YAML فائلیں شامل کرنا۔

GitLab CI میں متغیرات متعدد سطحوں پر سیٹ کیے جا سکتے ہیں: یوزر انٹرفیس میں عالمی طور پر، کنفیگریشن فائل میں، گروپ اور پروجیکٹ سیٹنگز میں۔ متغیر کی ترجیح ایک درجہ بندی کی پیروی کرتی ہے: ٹرگر متغیرات کی سب سے زیادہ ترجیح ہوتی ہے، پھر UI سے CI/CD متغیرات، پھر .gitlab-ci.yml سے۔ متغیرات کو محفوظ کیا جا سکتا ہے، جو انہیں صرف محفوظ برانچز اور ٹیگز کے لیے قابل رسائی بناتا ہے۔

بنیادی متغیرات اور امیج

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/

آرٹیفیکٹس کے ساتھ بلڈ کام

generate-apk کام Gradle پروجیکٹ بناتا ہے اور APK کو آرٹیفیکٹ کے طور پر محفوظ کرتا ہے۔ آرٹیفیکٹس سٹیجز کے درمیان منتقل ہوتے ہیں — deploy کام build سٹیج سے APK استعمال کر سکتا ہے۔ آرٹیفیکٹس کی برقراری 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 Android SDK کے ساتھ Docker امیجز کو ذخیرہ کرنے کے لیے بلٹ ان Container Registry فراہم کرتا ہے۔ GitHub Actions GitHub Packages یا بیرونی رجسٹریوں پر انحصار کرتا ہے۔ GitLab میں کوڈ کمزوری کے تجزیہ کے لیے بلٹ ان SAST (جامد ایپلیکیشن سکیورٹی ٹیسٹنگ) بھی ہے۔

GitLab CI زیادہ لچکدار رنر ماڈل پیش کرتا ہے — یہ Kubernetes ایکزیکیوٹر، خودکار پیمائش اور حسب ضرورت امیجز کو سپورٹ کرتا ہے۔ GitHub Actions GitHub ایکو سسٹم انضمام اور ایکشن مارکیٹ پلیس میں بہتر ہے۔ GitLab CI کو بہت سے کاموں کے لیے دستی کنفیگریشن درکار ہوتی ہے جبکہ GitHub Actions انہیں تیار ایکشنز سے حل کرتا ہے۔

موبائل CI/CD کے نقطہ نظر سے: GitLab CI ان کمپنیوں کے لیے زیادہ موزوں ہے جو پہلے سے GitLab Self-Managed استعمال کر رہی ہیں اور Docker/Kubernetes کے ساتھ خود میزبانی والے رنرز کی ضرورت ہے۔ GitHub Actions کلاؤڈ GitHub پر چھوٹی ٹیموں کے لیے زیادہ آسان ہے جو تیار ایکشنز اور سیٹ اپ کی سادگی کو اہمیت دیتی ہیں۔

خصوصیات کا موازنہ

Android پروجیکٹ کے لیے پائپ لائن کی مثال

مکمل Android پائپ لائن میں شامل ہے: lint، یونٹ ٹیسٹ، بلڈ اور Firebase App Distribution میں تعیناتی۔ پائپ لائن استعمال کرتی ہے Android SDK کے ساتھ Docker امیج، Gradle کیشنگ، اور ایک ہی سٹیج میں lint اور test کا متوازی نفاذ۔ یہ نقطہ نظر مجموعی پائپ لائن وقت کو کم کرتا ہے کیونکہ lint اور test کے کام ایک دوسرے سے آزاد ہوتے ہیں۔

iOS پروجیکٹس کے لیے، پائپ لائن کا ڈھانچہ macOS رنر اور کوڈ دستخط کی ضرورت کی وجہ سے مختلف ہوتا ہے۔ ایک عام iOS پائپ لائن میں شامل ہے: CocoaPods یا SPM کی تنصیب، سمیلیٹر پر ٹیسٹ چلانا، Xcode پروجیکٹ کو آرکائیو کرنا، IPA برآمد کرنا اور TestFlight میں اپ لوڈ کرنا۔ GitLab CI for iOS macOS رنرز استعمال کرتا ہے — یا تو وقت کی حدود کے ساتھ GitLab SaaS macOS رنرز یا 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 فراہم کرتا ہے — پائپ لائن کی مدت کے میٹرکس، رنر لوڈ اور رکاوٹوں والا ڈیش بورڈ۔ بہتری کے مواقع تلاش کرنے کے لیے ان میٹرکس کا باقاعدگی سے تجزیہ کریں۔ resource_group کو ترتیب دینے سے متوازی پائپ لائن رنز مسدود ہو جاتے ہیں — تعیناتی کے تنازعات کو روکنے کے لیے مفید۔

CI کے لیے برانچ حکمت عملی بھی اہم ہے۔ سفارش کی جاتی ہے کہ مکمل پائپ لائن صرف main اور release برانچز کے لیے چلائی جائے، اور فیچر برانچز کے لیے — صرف lint اور یونٹ ٹیسٹ۔ اس سے رنر منٹ بچتے ہیں اور ڈویلپر فیڈ بیک تیز ہوتا ہے۔ GitLab CI workflow:rules کو سپورٹ کرتا ہے — برانچ، تبدیل شدہ فائلوں یا ماحولی متغیرات کی بنیاد پر کاموں کو شامل یا خارج کرنے کے لیے مشروط اصول۔

انحصار کیشنگ بنیادی تیز رفتاری کا طریقہ ہے۔ GitLab CI رنز کے درمیان .gradle، Pods اور node_modules کو کیش کرتا ہے۔ کیش کلید میں $CI_COMMIT_REF_SLUG یا لاک فائل ہیش شامل ہے۔ مناسب کیشنگ کے ساتھ Android پروجیکٹ کا بلڈ ٹائم 10–15 سے 2–4 منٹ تک کم ہو جاتا ہے۔ کیش تقسیم کیا جا سکتا ہے — GitLab پچھلی کلیدوں پر فال بیک کے ساتھ cache:key کو سپورٹ کرتا ہے۔

پہلے سے نصب ٹولز والی Docker امیج تنصیب کا وقت بچاتی ہے۔ سفارش کی جاتی ہے کہ Android SDK، NDK اور مطلوبہ API لیول کے ساتھ ایک حسب ضرورت امیج بنائی جائے۔ مختلف سٹیجز میں کاموں (lint, test, assemble) کا متوازی نفاذ مجموعی پائپ لائن وقت کم کرتا ہے۔ امیجز کے لیے پل پالیسیاں (if-not-present) کام شروع کرنے میں تیزی لاتی ہیں۔ GitLab انسٹینس لیول پر امیجز کیش کرنے کے لیے انحصار پراکسی بھی استعمال کی جا سکتی ہے۔

بہتری کا ایک اور اہم پہلو سٹیجز کے درمیان آرٹیفیکٹس کا استعمال ہے۔ بھاری فائلیں جیسے APK اور IPA کو ہر کام میں دوبارہ بنانے کے بجائے dependency کے ذریعے منتقل کیا جانا چاہیے۔ درجنوں ماڈیولز والے بڑے پروجیکٹس کے لیے، پائپ لائن لیول پر Gradle Build Cache کو فعال کرنے اور مشترکہ اسٹوریج پر ریموٹ کیش ترتیب دینے کی سفارش کی جاتی ہے۔ ہر کام کے لیے ٹائم آؤٹ متوقع بلڈ ٹائم کی بنیاد پر سیٹ کیا جانا چاہیے — یہ پھنسے ہوئے عمل کو روکتا ہے۔

کیشنگ اور پل پالیسی کی مثال

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

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