موبائل ڈیولپمنٹ میں Build Pipeline — جوہر، مراحل اور ترتیب

Build Pipeline کیا ہے

Build Pipeline مراحل کا ایک رسمی سلسلہ ہے جو کوڈ کی ہر تبدیلی کے ساتھ خود بخود انجام پاتے ہیں۔ ہر مرحلہ معیار کے ایک خاص پہلو کی جانچ کرتا ہے: کمپائل ہونے کی صلاحیت، ٹیسٹوں کی درستی، کمزوریوں کی عدم موجودگی، کوڈ اسٹائل کی تعمیل۔ اگر کوئی مرحلہ ناکام ہو جاتا ہے تو پائپ لائن رک جاتی ہے۔

پائپ لائن کا تصور پروڈکشن لائن سے آیا ہے — جیسے فیکٹری میں جہاں ہر اسٹیشن مصنوعات میں قدر کا اضافہ کرتا ہے۔ ڈیولپمنٹ میں، ہر مرحلہ اعتماد کا اضافہ کرتا ہے کہ کوڈ ریلیز کے لیے تیار ہے۔ جدید پائپ لائنیں کوڈ کے طور پر بیان کی جاتی ہیں (Pipeline as Code) اور پروجیکٹ کے ساتھ Git ریپوزٹری میں محفوظ کی جاتی ہیں۔

Continuous Delivery Foundation، 2025 کے مطابق، ایک پختہ build-pipeline کمٹ سے ریلیز تک کے وقت کو ہفتوں سے منٹوں میں کم کر دیتی ہے۔ یہ مکمل آٹومیشن اور آزاد مراحل کے متوازی عملدرآمد کے ذریعے حاصل کیا جاتا ہے۔

Pipeline as Code

ویب انٹرفیس کے ذریعے ترتیب دینے کے بجائے، جدید پائپ لائن کو YAML یا Groovy فائلوں میں بیان کیا جاتا ہے۔ Jenkinsfile، `.gitlab-ci.yml`، `.github/workflows/build.yml` Pipeline as Code کی مثالیں ہیں۔ فوائد: ورژننگ، کوڈ ریویو، تولیدی صلاحیت۔

اعلانیہ (Declarative) بمقابلہ اسکرپٹڈ (Scripted) Pipeline

Jenkins میں دو نحویں ہیں۔ اعلانیہ — آسان، واضح stages/steps ساخت کے ساتھ۔ اسکرپٹڈ — زیادہ لچکدار، Groovy پر مبنی۔ زیادہ تر پروجیکٹس کے لیے اعلانیہ طریقہ کار تجویز کیا جاتا ہے کیونکہ یہ زیادہ پڑھنے کے قابل اور پیش قیاسی ہے۔

عام پائپ لائن کے مراحل

موبائل ایپلیکیشن کے لیے ایک عام build-pipeline میں کئی اہم مراحل شامل ہوتے ہیں۔ ہر مرحلہ اپنا کام انجام دیتا ہے اور ممکنہ مسائل کو ابتدائی مرحلے میں فلٹر کرتا ہے۔

چیک آؤٹ اور انحصار کی تنصیب

پائپ لائن ریپوزٹری کو کلون کرنے سے شروع ہوتی ہے۔ پھر انحصار نصب کیے جاتے ہیں: Gradle/Maven پیکیجز، CocoaPods، SPM (Swift Package Manager)، npm پیکیجز۔ اس مرحلے پر کیشنگ کا استعمال بعد کے بلڈز کو 50-70% تیز کرتا ہے۔

لنٹنگ اور جامد تجزیہ

کمپائلیشن سے پہلے، کوڈ کوالٹی ٹولز چلائے جاتے ہیں: Kotlin کے لیے Detekt یا ktlint، Swift کے لیے SwiftLint، JavaScript کے لیے ESLint۔ وہ کوڈ اسٹائل کی تعمیل کی جانچ کرتے ہیں اور کوڈ تجزیہ کی سطح پر ممکنہ بگز تلاش کرتے ہیں۔

کمپائلیشن اور یونٹ ٹیسٹ

کوڈ بائنری شکل میں کمپائل کیا جاتا ہے، یونٹ ٹیسٹ متوازی طور پر چلتے ہیں۔ Android کے لیے یہ `./gradlew testDebugUnitTest` ہے، iOS کے لیے — `xcodebuild test -scheme App -destination 'platform=iOS Simulator'`۔ ٹیسٹ کی ناکامی فوری طور پر پائپ لائن کو روک دیتی ہے۔

name: Mobile Build Pipeline
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew detekt

  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew jacocoTestReport

  build-release:
    needs: [lint, unit-tests]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk

انٹیگریشن اور UI ٹیسٹ

کامیاب کمپائلیشن کے بعد، وہ ٹیسٹ انجام دیے جاتے ہیں جن کے لیے ایپلیکیشن چلانے کی ضرورت ہوتی ہے: Android کے لیے Espresso، iOS کے لیے XCTest/XCUITest، React Native کے لیے Detox۔ اس مرحلے پر، آرٹیفیکٹ کو فارم سروسز (Firebase Test Lab، BrowserStack، Sauce Labs) کے ذریعے سمیلیٹر یا حقیقی ڈیوائس پر تعینات کیا جاتا ہے۔

پائپ لائن کی ترتیب

پائپ لائن کی صحیح ترتیب پورے CI/CD عمل کی کارکردگی کا تعین کرتی ہے۔ ترتیب میں شامل ہے ٹرگرز کا انتخاب، متوازی اور ترتیب وار مراحل کی وضاحت، پیرامیٹرائزیشن اور بیرونی خدمات کے ساتھ انضمام۔

پائپ لائن ٹرگرز

بنیادی ٹرگرز: ریپوزٹری میں push، pull request (خاص طور پر خودکار جانچوں کے ساتھ کوڈ ریویو کے لیے)، Git ٹیگ بنانا (ریلیز بلڈ کے لیے)، شیڈول (nightly build)۔ Pull request ٹرگر ٹیم ورک کے لیے سب سے زیادہ عملی ہے کیونکہ یہ کوڈ انضمام سے پہلے مسائل کی نشاندہی کرتا ہے۔

متوازی اور ترتیب وار مراحل

آزاد مراحل (لنٹنگ، مختلف OS ورژنز پر ٹیسٹنگ) کو تیز رفتاری کے لیے متوازی طور پر چلنا چاہیے۔ منحصر مراحل — ترتیب وار۔ جدید CI سسٹمز متوازی کاموں کو خود بخود منظم کرتے ہیں، انہیں دستیاب ایجنٹوں پر تقسیم کرتے ہیں۔

• Fail-fast — کسی بھی متوازی شاخ میں غلطی پر فوری ناکامی ترتیب دیں
• Matrix build — ایک بلڈ کو متعدد ترتیبات (API Level، Xcode ورژن) پر چلانا
• مشروط مراحل — کچھ مراحل صرف مخصوص شاخوں کے لیے چلتے ہیں (مثال کے طور پر، صرف main سے تعیناتی)

Build Pipeline کو بہتر بنانا

لمبی پائپ لائن ترقیاتی دور کو سست کرتی ہے اور ٹیم کے حوصلے کو کم کرتی ہے۔ بلڈ وقت کی بہتری build pipeline کے ساتھ کام کرتے وقت DevOps انجینئر کے اہم کاموں میں سے ایک ہے۔

انحصار کیشنگ

Gradle Build Cache پچھلی کمپائلیشنز کے نتائج محفوظ کرتا ہے۔ اگر کسی ماڈیول کا سورس کوڈ تبدیل نہیں ہوا ہے، تو اسے دوبارہ کمپائل نہیں کیا جاتا۔ Swift اور Kotlin میں انکریمنٹل کمپائلیشن اسی طرح کام کرتی ہے۔ کیش کا سائز گیگا بائٹس تک پہنچ سکتا ہے، لیکن وقت کی بچت 30% سے 70% تک ہوتی ہے۔

ٹیسٹوں کا متوازی عملدرآمد

یونٹ ٹیسٹ ایک ساتھ متعدد ایجنٹوں پر چلائے جا سکتے ہیں، ٹیسٹ کلاسز تقسیم کر کے۔ Sharding ٹیسٹوں کو گروپس (shards) میں تقسیم کرنے کی تکنیک ہے۔ GitHub Actions `strategy.matrix` کو سپورٹ کرتا ہے، Jenkins — Parallel Test Executor، Gradle — `--parallel --max-workers`۔

پائپ لائن کی تہوں کو کم سے کم کرنا

ہر اضافی مرحلہ وقت بڑھاتا ہے۔ باقاعدگی سے پائپ لائن کا تجزیہ کریں: کن مراحل کو یکجا کیا جا سکتا ہے؟ مثال کے طور پر، لنٹنگ کو کمپائلیشن سے پہلے کی بجائے اس کے متوازی چلایا جا سکتا ہے۔ انٹیگریشن ٹیسٹ — صرف pull request کے لیے، ہر commit کے لیے نہیں۔

pipeline {
    agent any
    options {
        timestamps()
        timeout(time: 30, unit: 'MINUTES')
    }
    stages {
        stage('Parallel Checks') {
            parallel {
                stage('Lint') {
                    steps { sh './gradlew detekt' }
                }
                stage('Unit Tests') {
                    steps { sh './gradlew test' }
                }
            }
        }
        stage('Build') {
            steps { sh './gradlew assembleRelease' }
        }
    }
}

Build Pipeline کی حفاظت

Build pipeline سافٹ ویئر سپلائی چین کا ایک اہم عنصر ہے، اور اس کی حفاظت کو نظر انداز نہیں کیا جا سکتا۔ پائپ لائن سے سمجھوتہ ریلیز آرٹیفیکٹ میں بدنیتی پر مبنی کوڈ داخل کرنے کا سبب بن سکتا ہے، جس سے ایپلیکیشن کے تمام صارفین متاثر ہوں گے۔

پائپ لائنوں پر سپلائی چین حملے

معروف حملے: SolarWinds (2020)، Codecov (2021)، 3CX (2023) — سبھی نے CI/CD پائپ لائنوں میں کمزوریوں کا فائدہ اٹھایا۔ مشترکہ ویکٹر — حملہ آور بلڈ سرور کی اسناد تک رسائی حاصل کرتا ہے اور بلڈ مرحلے پر کوڈ میں تبدیلی کرتا ہے۔ نتیجہ — ایک جائز سرٹیفکیٹ کے ساتھ دستخط شدہ بدنیتی پر مبنی ریلیز۔

اسناد کی حفاظت

کبھی ذخیرہ نہ کریں دستخطی چابیاں، API ٹوکنز اور پاس ورڈز ریپوزٹری یا CI سسٹم کے ماحولیاتی متغیرات میں سادہ متن میں۔ CI سسٹم کے راز (GitHub Secrets، GitLab CI Variables)، HashiCorp Vault، AWS Secrets Manager استعمال کریں۔ رازوں تک رسائی کو کم سے کم کریں — ہر پائپ لائن کو صرف اپنے مخصوص مراحل کے لیے ضروری چابیاں ملنی چاہئیں۔

پائپ لائن آرٹیفیکٹ کی تصدیق

پائپ لائن سے نکلنے والا ہر آرٹیفیکٹ خفیہ نگاری سے دستخط شدہ ہونا چاہیے اور اس میں تصدیق (attestation) — ماخذ کا ثبوت (provenance) شامل ہونا چاہیے۔ اوزار: SLSA فریم ورک، in-toto attestation، کنٹینرز پر دستخط کے لیے cosign۔ کسی بھی ماحول میں تعیناتی سے پہلے دستخط کی تصدیق کی جانی چاہیے۔

name: Secure Build Pipeline
on: [push]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan dependencies
        run: ./gradlew dependencyCheckAnalyze
      - name: SAST scan
        run: ./gradlew detekt

  sign-attest:
    needs: security-scan
    runs-on: ubuntu-latest
    steps:
      - run: ./gradlew assembleRelease
      - name: Sign APK
        run: jarsigner -keystore ${{ secrets.KEYSTORE }} \
          app-release.apk ${{ secrets.KEY_ALIAS }}
      - name: Generate provenance
        uses: actions/attest-build-provenance@v1

پائپ لائن کی نگرانی اور ڈیبگنگ

Build pipeline ایک پیچیدہ نظام ہے جسے مسلسل نگرانی کی ضرورت ہے۔ میٹرکس کے بغیر، یہ تعین کرنا ناممکن ہے کہ پائپ لائن سست ہوئی ہے اور کون سا مرحلہ رکاوٹ بن گیا ہے۔

پائپ لائن میٹرکس

ٹریک کریں: پائپ لائن کی کل مدت، ہر مرحلے کا وقت، بلڈ ناکامی کی شرح، قطار کا انتظار کا وقت۔ بڑی ٹیم (>20 ڈیولپرز) کے لیے، Grafana یا Datadog میں ہفتہ/ماہ کے لیے مجموعی اعدادوشمار کے ساتھ ڈیش بورڈ ترتیب دینے کی سفارش کی جاتی ہے۔

ناکامی سے آگاہی

پائپ لائن کی ہر ناکامی پر ردعمل کی ضرورت ہے۔ پیغام رسانی ایپس (Slack، Telegram، Discord) میں خرابی لاگ کا لنک اور کمٹ مصنف کے نام کے ساتھ اطلاعات ترتیب دیں۔ سنگین ناکامیوں کے لیے — ایسکلیشن کے ساتھ PagerDuty یا Opsgenie۔

مقامی پائپ لائن ڈیبگنگ

Act (GitHub Actions کے لیے) یا Jenkins Pipeline Unit Test جیسے اوزار کمٹ کیے بغیر پائپ لائن کو مقامی طور پر چلانے کی اجازت دیتے ہیں۔ یہ پائپ لائن کی ترقی اور ڈیبگنگ کو تیز کرتا ہے، خاص طور پر نئے مراحل شامل کرتے وقت یا ترتیب تبدیل کرتے وقت۔