Continuous Integration (CI) — یہ کیا ہے، اصول اور آٹومیشن سیٹ اپ

Continuous Integration کیا ہے

Continuous Integration (CI) ایک ڈویلپمنٹ طریقہ کار ہے جو متعدد شراکت داروں سے کوڈ کو ایک ہی کوڈبیس میں ضم کرنے کے عمل کو خودکار بناتا ہے۔ یہ اصطلاح 2000 کی دہائی کے اوائل میں Martin Fowler نے “انضمام کی جہنم” کو روکنے کے لیے طریقوں کے ایک سیٹ کے طور پر متعارف کروائی تھی — ایسی صورت حال جہاں ڈویلپر ہفتوں تک الگ تھلگ کام کرتے ہیں اور تبدیلیوں کو ضم کرتے وقت بے شمار تضادات پیدا ہوتے ہیں جنہیں حل کرنے میں دن لگ جاتے ہیں۔

CI کس مسئلے کو حل کرتا ہے

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

CI کا معاشی اثر

IBM Systems Sciences Institute کے مطابق، کوڈنگ مرحلے میں بگ کی اصلاح کی لاگت $25، ٹیسٹنگ مرحلے میں $100، اور پروڈکشن مرحلے میں $2,500 ہے۔ CI نقائص کا پتہ لگانے کو جتنا ممکن ہو بائیں (shift left) منتقل کرتا ہے، کمٹ مرحلے میں غلطیاں ڈھونڈتا ہے جب ان کی اصلاح تقریباً مفت ہے۔ CI والی ٹیمیں ڈیبگنگ پر اوسطاً 15% وقت صرف کرتی ہیں، جبکہ CI کے بغیر ٹیمیں 35% وقت صرف کرتی ہیں۔

Continuous Integration کے بنیادی اصول

Martin Fowler نے CI کے اہم طریقوں کی وضاحت کی جو ٹیکنالوجی اسٹیک سے آزاد رہتے ہوئے متعلقہ رہتے ہیں۔ ان اصولوں پر عمل کرنا یقینی بناتا ہے کہ CI بیوروکریٹک بوجھ بننے کے بجائے قدر لاتا ہے۔ موبائل ڈویلپمنٹ اضافی تقاضے عائد کرتی ہے، لیکن بنیادی حصہ تبدیل نہیں ہوتا۔

ایک واحد ریپوزٹری

تمام پروجیکٹ کوڈ ایک ہی ریپوزٹری میں متحدہ ورژن کنٹرول سسٹم (Git) کے ساتھ محفوظ کیا جاتا ہے۔ سچائی کا ایک ذریعہ اس صورت حال کو ختم کرتا ہے جہاں ایک فیچر فورک میں تیار کیا جاتا ہے اور ہفتوں تک مرکزی کوڈبیس کے ساتھ ہم آہنگ نہیں ہوتا۔ موبائل پروجیکٹس میں، اس کا مطلب ہے کہ Android، iOS اور backend حصے ایک ہی ریپوزٹری (مونو ریپو) یا مشترکہ ورژننگ اسکیم والی علیحدہ ریپوزٹریوں میں ہو سکتے ہیں۔

خودکار بلڈ

پروجیکٹ بلڈ ایک ہی کمانڈ سے قابل عمل ہونا چاہیے۔ Android کے لیے یہ ./gradlew assembleDebug ہے، iOS کے لیے — xcodebuild یا fastlane build۔ بلڈ اسکرپٹ تولیدی پذیری کی تصدیق کرتا ہے: CI سرور پر بلڈ کا وہی نتیجہ ہونا چاہیے جو ڈویلپر کی مشین پر ہوتا ہے۔ ماحول میں کسی بھی فرق کو کنٹینرائزیشن یا IaC (Infrastructure as Code) کے ذریعے ختم کیا جاتا ہے۔

خودکار ٹیسٹ

بلڈ کے بعد، تمام سطحوں کے ٹیسٹ چلائے جاتے ہیں: یونٹ، انضمام اور UI۔ اگر ٹیسٹ ناکام ہوتے ہیں تو کمٹ کو غلط سمجھا جاتا ہے۔ سبز حیثیت برقرار رکھنا ٹیم کی مشترکہ ذمہ داری ہے۔ موبائل پروجیکٹس میں، تیز ٹیسٹ (فی کمٹ 5 منٹ کے اندر چلنے والے) اکثر سست ٹیسٹ (حقیقی آلات پر UI ٹیسٹ، کم کثرت سے چلائے جاتے ہیں) سے الگ کیے جاتے ہیں۔

// CI دوستانہ رپورٹ کے ساتھ یونٹ ٹیسٹ کی مثال
class LoginViewModelTest {

    private val repository = mock<AuthRepository>()
    private val viewModel = LoginViewModel(repository)

    @Test
    fun loginWithValidCredentials_success() {
        val email = "test@example.com"
        val password = "ValidPass123"

        whenever(repository.login(email, password))
            .thenReturn(Result.success(User("token-xyz")))

        val result = viewModel.login(email, password)

        assertEquals(LoginState.Success, result)
        verify(repository).login(email, password)
    }
}

Fail fast اور شفافیت

CI کے نتائج پوری ٹیم کے لیے عوامی ہوتے ہیں: ہر کوئی دیکھ سکتا ہے کہ کس کے کمٹ نے بلڈ توڑا۔ شفافیت احتساب کا کلچر بناتی ہے: ڈویلپر push کرنے سے پہلے اپنی تبدیلیوں کی جانچ کرتے ہیں اور ٹوٹے ہوئے بلڈ کو باری سے باہر ٹھیک کرتے ہیں۔ CI سرور بلڈ کی حیثیت تبدیل ہونے پر Slack یا Telegram پر اطلاع بھیجتا ہے۔

CI سسٹم کے اجزاء

مکمل CI سسٹم کئی اجزاء پر مشتمل ہوتا ہے جو ایک دوسرے کے ساتھ تعامل کرتے ہیں۔ ہر جزو پائپ لائن کے اپنے حصے کا ذمہ دار ہے: شروع کرنے سے لے کر رپورٹ تک۔ CI فن تعمیر کو سمجھنا مسائل کی تشخیص اور کارکردگی کو بہتر بنانے میں مدد کرتا ہے۔

CI سرور

مرکزی جزو جو بلڈ قطار، وسائل کی تقسیم اور نتائج کی اشاعت کا انتظام کرتا ہے۔ CI سرور کلاؤڈ بیسڈ (GitHub Actions، GitLab CI، CircleCI) یا سیلف ہوسٹڈ (Jenkins، TeamCity) ہو سکتا ہے۔ سرور ویب ہک یا پولنگ کے ذریعے ریپوزٹری میں تبدیلیوں کی نگرانی کرتا ہے اور ہر push یا pull request پر پائپ لائن شروع کرتا ہے۔

رنر اور ایجنٹ

رنر ورچوئل یا فزیکل مشینیں ہیں جو بلڈ کے کام انجام دیتی ہیں۔ کلاؤڈ CI میں، رنر فراہم کنندہ فراہم کرتا ہے اور استعمال کے وقت کے مطابق بل کیا جاتا ہے۔ سیلف ہوسٹڈ رنر اپنے انفراسٹرکچر پر نصب کیے جاتے ہیں اور انہیں دیکھ بھال کی ضرورت ہوتی ہے۔ iOS بلڈ کے لیے macOS رنر درکار ہیں، Android بلڈ کے لیے Linux یا Windows درکار ہے۔

آرٹیفیکٹ اور کیش

بلڈ کے بعد، CI سسٹم آرٹیفیکٹ (APK، IPA، ٹیسٹ رپورٹس) کو اسٹوریج میں محفوظ کرتا ہے — یہ ڈاؤن لوڈ اور ڈپلائمنٹ کے لیے دستیاب ہوتے ہیں۔ رنز کے درمیان انحصار کیشنگ (Gradle کیش، CocoaPods کیش) بعد کے بلڈ کو 3–5 گنا تیز کرتی ہے۔

موبائل ایپلیکیشنز کے لیے Continuous Integration

موبائل ڈویلپمنٹ میں CI کے لیے خصوصی تقاضے ہیں جو ویب یا backend پروجیکٹس سے مختلف ہیں۔ طویل بلڈ اوقات (Android کے لیے 3–15 منٹ، iOS کے لیے 5–20 منٹ)، متعدد قسم کے آرٹیفیکٹ (APK، AAB، IPA)، دستخط اور مبہم کرنے کی ضرورت — ان سب کے لیے CI پائپ لائن کی حسب ضرورت ترتیب درکار ہے۔

Android CI پائپ لائن

Android کے لیے عام CI میں شامل ہے: لنٹنگ (ktlint، detekt) اور جامد تجزیہ، JUnit اور MockK کے ساتھ یونٹ ٹیسٹ، ڈیبگ اور ریلیز APK/AAB کا بلڈ، CI کے اندر ایمولیٹر پر انسٹرومینٹیشن ٹیسٹ، اور آرٹیفیکٹ کی اشاعت۔ Gradle کیش بار بار ہونے والے بلڈ کو تیز کرتا ہے — اس کے بغیر، ہر بلڈ انحصار کو نئے سرے سے ڈاؤن لوڈ کرتا ہے، 3–5 منٹ کھو دیتا ہے۔

iOS CI پائپ لائن

iOS CI کو Swift/Objective-C کوڈ مرتب کرنے کے لیے macOS رنر کی ضرورت ہے۔ پائپ لائن میں شامل ہے: CocoaPods یا SPM انحصار کی تنصیب، اسٹائل چیک کے لیے SwiftLint، XCTest کے ساتھ یونٹ ٹیسٹ، IPA بلڈ، Fastlane match کے ذریعے کوڈ دستخط، اور TestFlight پر اپ لوڈ۔ ڈیٹا سینٹر میں Mac mini یا Mac پر سیلف ہوسٹڈ رنر کلاؤڈ macOS رنر کا متبادل ہے۔

کراس پلیٹ فارم پروجیکٹس (Flutter، React Native)

Flutter اور React Native دونوں پلیٹ فارمز کے لیے مقامی بلڈ میں مرتب ہوتے ہیں۔ CI کو دو رنر کی حمایت کرنی چاہیے: Android بلڈ کے لیے Linux اور iOS بلڈ کے لیے macOS۔ بہترین حکمت عملی ایک تقسیم شدہ پائپ لائن ہے: Linux رنر پر Android بلڈ، macOS رنر پر iOS بلڈ، جس کے بعد دونوں آرٹیفیکٹ ایک ہی ریلیز میں یکجا ہو جاتے ہیں۔

CI ٹولز کا موازنہ

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

GitHub Actions

عوامی ریپوزٹریوں کے لیے مفت (2000 منٹ/ماہ)۔ GitHub Actions Android (gradle/actions) اور iOS (apple-actions) کے لیے تیار ایکشنز کا ایکو سسٹم پیش کرتا ہے۔ نقصان یہ ہے کہ macOS رنر صرف ادائیگی کے منصوبوں پر دستیاب ہیں۔ اوپن سورس اور چھوٹی ٹیموں کے لیے مثالی جو پہلے سے GitHub استعمال کرتی ہیں۔

Jenkins

ایک سیلف ہوسٹڈ اوپن سورس CI سرور۔ Jenkins Groovy Pipeline کے ذریعے ترتیب دیا جاتا ہے، سینکڑوں پلگ ان کو سپورٹ کرتا ہے اور کسی بھی ہارڈویئر پر چلتا ہے۔ سیٹ اپ اور دیکھ بھال کے لیے DevOps انجینئر کی ضرورت ہے۔ انٹرپرائز سیگمنٹ میں مقبول جہاں انفراسٹرکچر پر کنٹرول اہم ہے۔

GitLab CI

کھلے رنر فن تعمیر کے ساتھ GitLab میں بلٹ ان CI/CD۔ GitLab CI مفت منصوبے پر اپنے رنر (macOS سمیت) استعمال کرنے کی اجازت دیتا ہے۔ YAML ترتیب GitHub Actions سے زیادہ طاقتور ہے لیکن سیکھنا مشکل ہے۔ ان ٹیموں کے لیے موزوں جو GitLab کو واحد DevOps پلیٹ فارم کے طور پر استعمال کرتی ہیں۔

CircleCI

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

CI سیٹ اپ کی مثال

GitHub Actions استعمال کرتے ہوئے Android پروجیکٹ کے لیے CI سیٹ اپ پر غور کریں۔ پائپ لائن main برانچ پر ہر push اور pull request پر جامد تجزیہ، بلڈ اور ٹیسٹنگ کرتی ہے۔ کم سے کم ترتیب میں 15 منٹ لگتے ہیں اور کسی بیرونی سروس کی ضرورت نہیں ہوتی۔

name: Android CI
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - run: ./gradlew ktlintCheck detekt

  unit-tests:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew testDebugUnitTest
      - uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/tests/

پائپ لائن دو متوازی جابز پر مشتمل ہے: lint (جامد تجزیہ کرتا ہے) اور unit-tests (lint پر منحصر — اگر لنٹنگ ناکام ہوتی ہے تو ٹیسٹ نہیں چلتے)۔ unit-tests جاب ٹیسٹ رپورٹ کو آرٹیفیکٹ کے طور پر اپ لوڈ کرتی ہے — ٹیم فائلیں مقامی طور پر ڈاؤن لوڈ کیے بغیر GitHub Actions UI میں اس کا جائزہ لے سکتی ہے۔

CI سے پہلے مقامی جانچ

معمولی غلطیوں کی وجہ سے CI کی ناکامی سے بچنے کے لیے، Git میں pre-push hook یا Gradle ٹاسک ترتیب دیں جو وہی جانچیں مقامی طور پر چلاتا ہے۔ مثال کے طور پر: ./gradlew ktlintCheck detekt testDebugUnitTest۔ اگر مقامی جانچ میں 3 منٹ سے زیادہ وقت لگتا ہے، تو انہیں تیز (لنٹر) اور سست (ٹیسٹ) میں تقسیم کریں، تیز جانچ ہر کمٹ سے پہلے اور سست جانچ صرف push سے پہلے چلائیں۔