CI/CD Pipeline — یہ کیا ہے، آٹومیشن کے مراحل اور اوزار

CI/CD Pipeline کیا ہے

CI/CD Pipeline عمل کا ایک رسمی اور خودکار مجموعہ ہے جس سے کوڈ ریپوزٹری میں تبدیلیاں کمٹ کرنے سے لے کر پروڈکشن میں تعیناتی تک گزرتا ہے۔ یہ اصطلاح دو طریقوں کو یکجا کرتی ہے: Continuous Integration (مسلسل انضمام) اور Continuous Delivery (مسلسل ترسیل)، جو مل کر سافٹ ویئر ڈیلیوری پائپ لائن بناتے ہیں۔

CI/CD کی تاریخ

Continuous Integration کا تصور 1991 میں گریڈی بوچ نے بیان کیا اور 2000 کی دہائی میں مارٹن فاؤلر نے مقبول بنایا۔ Continuous Delivery ایک اصطلاح کے طور پر جیز ہمبل اور ڈیوڈ فارلی کی کتاب «Continuous Delivery» (2010) کے بعد قائم ہوئی۔ جدید CI/CD Pipeline 2015 کے بعد کلاؤڈ CI سرورز اور ایپ اسٹور آٹومیشن کے ظہور کے ساتھ موبائل ڈویلپمنٹ میں حقیقی معیار بن گیا۔

موبائل ڈویلپمنٹ میں CI/CD Pipeline کیوں ضروری ہے

موبائل ایپلیکیشنز میں بلڈ اور اشاعت کے لیے مخصوص تقاضے ہوتے ہیں: سرٹیفکیٹ دستخط، متعدد کنفیگریشنز (debug، release، staging)، ProGuard/R8 مبہم کاری، متعدد بلڈ اقسام (APK، AAB، IPA) اور ایپ اسٹورز کے ساتھ انضمام۔ ان مراحل کا دستی نفاذ گھنٹے لگتا ہے اور غلطی کا شکار ہے — CI/CD Pipeline معمول کو خودکار بناتا ہے۔

موبائل ایپس کے لیے CI/CD Pipeline کے مراحل

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

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

پائپ لائن ریپوزٹری کلون کرنے اور انحصار انسٹال کرنے سے شروع ہوتی ہے: Android کے لیے Gradle/Maven، iOS کے لیے CocoaPods یا SPM۔ رنز کے درمیان انحصار کیشنگ تنصیب کے وقت کو 3–5 منٹ سے کم کرکے چند سیکنڈ کر دیتی ہے — تمام جدید CI خدمات اس اصلاح کو سپورٹ کرتی ہیں۔

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

بلڈ سے پہلے، کوڈ لنٹرز (Android کے لیے ktlint، detekt، iOS کے لیے SwiftLint) اور جامد تجزیہ کاروں (Android Lint، SonarQube) سے جانچا جاتا ہے۔ لِنٹنگ ٹیسٹ چلانے سے پہلے ممکنہ بگز، کوڈ اسٹائل کی خلاف ورزیاں اور متروک APIs کا پتہ لگاتا ہے — فیل-فاسٹ اصول ٹیم کا وقت بچاتا ہے۔

3. پروجیکٹ بلڈ

بلڈ مرحلے پر، پورا پروجیکٹ کمپائل ہوتا ہے اور آرٹیفیکٹس تیار ہوتے ہیں: Android کے لیے APK اور AAB، iOS کے لیے IPA۔ Android کے لیے Gradle tasks (assembleDebug، bundleRelease) استعمال ہوتے ہیں، iOS کے لیے — xcodebuild یا xcrun۔ بلڈ CI سرور کے الگ تھلگ ماحول میں انجام پاتا ہے، جو تولیدی صلاحیت کو یقینی بناتا ہے۔

# GitHub Actions پر Android کے لیے CI/CD Pipeline کی مثال
name: Android CI Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew ktlintCheck detekt
      - run: ./gradlew assembleDebug
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/*.apk

4. خودکار جانچ

بلڈ کے بعد، یونٹ ٹیسٹ، انضمام ٹیسٹ اور UI ٹیسٹ چلتے ہیں۔ یونٹ ٹیسٹ کے لیے JUnit اور MockK، Android UI کے لیے Espresso اور Compose Test، iOS کے لیے XCTest اور XCUITest۔ نتائج ایک رپورٹ میں شائع ہوتے ہیں اور اہم ٹیسٹ ناکام ہونے پر پائپ لائن کو روک دیتے ہیں۔

5. دستخط اور مبہم کاری

ریلیز بلڈ کے لیے، ڈیجیٹل سرٹیفکیٹ دستخط (Android کے لیے APK Signer، iOS کے لیے codesign) اور کوڈ مبہم کاری کی جاتی ہے۔ Android کے لیے ProGuard یا R8 APK کا حجم 15–30% تک کم کرتا ہے۔ دستخطی کنجیاں CI سرور کے رازوں میں محفوظ ہوتی ہیں — ریپوزٹری میں کبھی کمٹ نہیں کی جاتیں۔

6. ترسیل اور تعیناتی

پائپ لائن کا آخری مرحلہ آرٹیفیکٹس کی اشاعت ہے: Google Play Console داخلی جانچ میں APK اپ لوڈ کرنا، TestFlight میں IPA بھیجنا یا Firebase Distribution میں شائع کرنا۔ مسلسل ترسیل کا مطلب ہے کہ اس مرحلے میں دستی منظوری درکار ہے، جبکہ مسلسل تعیناتی خودکار طور پر چلتی ہے۔

7. اطلاعات اور رپورٹس

پائپ لائن مکمل ہونے کے بعد، ٹیم کو نتائج کی اطلاع ملتی ہے: کامیابی/ناکامی، عملدرآمد کا وقت، آرٹیفیکٹ لنک۔ Slack، Telegram یا ای میل — اطلاعی چینلز ٹیم کی ضروریات کے مطابق منتخب کیے جاتے ہیں۔ جب کوئی مرحلہ ناکام ہوتا ہے، اطلاع میں مخصوص خرابی لاگ کا لنک شامل ہوتا ہے۔

CI اور CD میں فرق

CI اور CD کی اصطلاحات اکثر ایک ہی تصور CI/CD کے طور پر استعمال ہوتی ہیں، لیکن ان کے درمیان بنیادی فرق ہے۔ CI (مسلسل انضمام) ہر کوڈ انضمام پر معیار کی جانچ کا ذمہ دار ہے، جبکہ CD (مسلسل ترسیل) ریلیز کے لیے کوڈ کی تیاری کو یقینی بناتا ہے۔ پائپ لائن ڈیزائن کرتے وقت فرق کو سمجھنا بہت اہم ہے۔

Continuous Integration — معیار کی جانچ

CI ہر push یا pull request پر چلتا ہے اور بلڈ، جامد تجزیہ اور جانچ شامل کرتا ہے۔ CI کا مقصد مسائل کو جلد از جلد پکڑنا ہے، جب ان کی اصلاح کی لاگت کم سے کم ہوتی ہے۔ اگر CI ناکام ہوتا ہے — کوڈ مرکزی شاخ میں داخل نہیں ہوتا۔ موبائل پروجیکٹ کے لیے اوسط CI عملدرآمد کا وقت 5–15 منٹ ہے۔

Continuous Delivery — ریلیز کی تیاری

CD CI میں ریلیز کی تیاری کے مراحل شامل کرتا ہے: دستخط، مبہم کاری، ریلیز نوٹس کی تخلیق، لائسنس کی جانچ، ٹیسٹرز کے لیے ذخیرہ میں اشاعت۔ CD ضمانت دیتا ہے کہ مرکزی شاخ میں کوئی بھی کمٹ ایک کلک سے پروڈکشن میں بھیجا جا سکتا ہے، لیکن ریلیز خود دستی منظوری کی متقاضی ہے۔

CI/CD Pipeline بنانے کے اوزار

موبائل ڈویلپمنٹ کے لیے CI/CD اوزاروں کا ماحولیاتی نظام کلاؤڈ سروسز، خود میزبان حل اور خصوصی پلیٹ فارمز پر مشتمل ہے۔ آلے کا انتخاب ٹیم کے سائز، بجٹ اور سیکیورٹی کی ضروریات پر منحصر ہے۔ ذیل میں سب سے مشہور اختیارات ہیں۔

GitHub Actions

GitHub میں بلٹ ان CI/CD، عوامی ذخیروں کے لیے ماہانہ 2000 منٹ کی مفت حد کے ساتھ۔ GitHub Actions تیار ایکشنز کے بہت بڑے ماحولیاتی نظام (مارکیٹ پلیس)، YAML کے ذریعے آسان ترتیب اور GitHub ذخیروں کے ساتھ ہموار انضمام کی وجہ سے مقبول ہے۔ حد — مفت منصوبے میں iOS بلڈ کے لیے Windows رنر کی معاونت نہیں ہے۔

GitLab CI/CD

طاقتور YAML کنفیگریٹر کے ساتھ خود میزبان اور کلاؤڈ حل۔ GitLab CI متوازی ملازمتوں، کیشنگ، آرٹیفیکٹس اور ماحول کی حمایت کرتا ہے۔ اپنے بنیادی ڈھانچے پر تعیناتی کی صلاحیت اور ڈیٹا پر مکمل کنٹرول کی وجہ سے انٹرپرائز طبقہ میں مقبول۔

Jenkins

کلاسک اوپن سورس CI سرور۔ Jenkins پلگ انز (1800 سے زیادہ) کے ذریعے ترتیب دیا جاتا ہے، Groovy فارمیٹ میں Declarative Pipeline کو سپورٹ کرتا ہے اور کسی بھی ماحول میں چلتا ہے: Windows، macOS، Linux۔ وقف انتظامیہ درکار ہے لیکن زیادہ سے زیادہ ترتیب لچک فراہم کرتا ہے۔

CircleCI

رفتار اور سادگی پر مرکوز کلاؤڈ CI سروس۔ CircleCI خود بخود انحصار کو کیش کرتا ہے، الگ تھلگ بلڈ کے لیے Docker امیجز کو سپورٹ کرتا ہے اور iOS بلڈ کے لیے macOS کے ساتھ مربوط ہوتا ہے۔ قیمت کریڈٹ پر مبنی ہے — کارکردگی کو اہمیت دینے والی ٹیموں کے لیے موزوں۔

CI/CD Pipeline سیٹ اپ مثال

آئیے GitHub Actions اور Fastlane استعمال کرتے ہوئے iOS ایپ کے لیے ایک مکمل CI/CD Pipeline دیکھتے ہیں۔ Fastlane موبائل پروجیکٹس کے لیے ایک آٹومیشن ٹول ہے جو پیچیدہ بلڈ، دستخط اور اشاعت کے عمل کو سادہ کمانڈز میں سمیٹتا ہے۔

# Fastfile — iOS CI/CD کے لیے Fastlane کی ترتیب
default_platform(:ios)

platform :ios do
  desc "ٹیسٹ اور لِنٹنگ چلانا"
  lane :ci do
    cocoapods
    swiftlint
    run_tests(scheme: "MyApp", devices: ["iPhone 16 Pro"])
  end

  desc "ریلیز بلڈ اور TestFlight میں اپ لوڈ"
  lane :release do
    match(type: "appstore")
    build_app(scheme: "MyApp", export_method: "app-store")
    pilot(skip_waiting_for_build: true)
  end
end

Fastlane match سرٹیفکیٹس اور پروویژننگ پروفائلز کا انتظام کرتا ہے، build_app IPA بناتا ہے، pilot بلڈ کو TestFlight پر اپ لوڈ کرتا ہے۔ fastlane release کمانڈ تمام مراحل کو ترتیب وار انجام دیتا ہے: سرٹیفکیٹ حاصل کرتا ہے، بناتا ہے، دستخط کرتا ہے، بیٹا ٹیسٹرز کے لیے App Store Connect پر اپ لوڈ کرتا ہے۔

GitHub Actions کے ساتھ iOS کے لیے CI/CD Pipeline

Fastlane کو GitHub Actions کے ساتھ ضم کرنا مرکزی شاخ میں pull request پر مکمل پائپ لائن کو خود بخود چلانے کی اجازت دیتا ہے۔ iOS کوڈ کمپائلیشن کے لیے macOS پر خود میزبان رنر ضروری ہے — GitHub مفت منصوبے میں macOS رنر فراہم نہیں کرتا۔

name: iOS CI/CD Pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  ci-checks:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.3
      - run: bundle install
      - run: bundle exec fastlane ci
      - if: github.ref == 'refs/heads/main'
        run: bundle exec fastlane release
        env:
          MATCH_PASSWORD: ${{ secrets.MATCH_PASSWORD }}
          FASTLANE_APPLE_ID: ${{ vars.APPLE_ID }}

CI/CD Pipeline بہترین طریقوں

ایک مؤثر CI/CD Pipeline بنانے کے لیے نہ صرف اوزاروں کا انتخاب بلکہ ثابت شدہ طریقوں پر عمل کرنا بھی ضروری ہے۔ مناسب تنظیم کے بغیر، پائپ لائن ایک رکاوٹ بن سکتی ہے، جو ترقی کو تیز کرنے کے بجائے سست کر دیتی ہے۔ ذیل میں پختہ موبائل ٹیموں کے تجربے پر مبنی اہم سفارشات ہیں۔

Fail Fast (تیزی سے ناکام ہوں)

سب سے تیز جانچیں (لِنٹنگ، یونٹ ٹیسٹ) پہلے چلتی ہیں۔ اگر وہ ناکام ہوتی ہیں — پائپ لائن لمبے UI ٹیسٹ یا ریلیز بلڈ چلائے بغیر ختم ہو جاتی ہے۔ Fail fast CI وقت کے منٹ بچاتا ہے اور ڈویلپر کو فیڈ بیک کو تیز کرتا ہے۔ پہلی ناکامی تک کا اوسط وقت 2–3 منٹ سے زیادہ نہیں ہونا چاہیے۔

انحصار کیشنگ

Gradle کیش، CocoaPods کیش اور SPM کیش رنز کے درمیان بحال کیا جانا چاہیے۔ GitHub Actions actions/cache کے ذریعے کیشنگ کو سپورٹ کرتا ہے، GitLab CI cache کلید لفظ کے ذریعے۔ کیشنگ کے بغیر، ہر بلڈ تمام انحصار نئے سرے سے ڈاؤن لوڈ کرتا ہے — پائپ لائن کے وقت میں 3–10 منٹ کا اضافہ۔

متوازی عملدرآمد

آزاد مراحل (Android اور iOS کے لیے لنٹر، مختلف ماڈیولز کے یونٹ ٹیسٹ) متوازی ملازمتوں کے طور پر چلتے ہیں۔ متوازی کاری کل پائپ لائن کے وقت کو 20–30 منٹ سے کم کرکے 5–10 منٹ کر دیتی ہے۔ زیادہ تر CI خدمات متوازی ملازمتوں کے لیے علیحدہ چارج کرتی ہیں — منصوبہ منتخب کرتے وقت اسے ذہن میں رکھیں۔

ماحول کی علیحدگی

ہر پائپ لائن رن صاف ماحول میں انجام پاتا ہے: Docker کنٹینر، ورچوئل مشین یا عارضی رنر۔ علیحدگی پچھلے بلڈ کو موجودہ کو متاثر کرنے سے روکتی ہے۔ پروجیکٹس کے درمیان مشترکہ رنر استعمال کرنے سے گریز کریں — کراس پروجیکٹ ماحولیاتی آلودگی غیر متعین ناکامیوں کا باعث بنتی ہے۔

رازوں کی حفاظت

API کنجیاں، دستخطی سرٹیفکیٹس اور ایپ اسٹور تک رسائی کے ٹوکن CI سرور کے خفیہ کردہ والٹ میں محفوظ ہوتے ہیں۔ SECRET_ سابقہ کے بغیر لاگز، آرٹیفیکٹس یا ماحولیاتی متغیرات میں رازوں کو کبھی شامل نہ کریں۔ iOS سرٹیفکیٹ مینجمنٹ کے لیے Fastlane match جیسے اوزار استعمال کریں۔