Continuous Integration (CI) — এটি কী, নীতি এবং অটোমেশন সেটআপ

Continuous Integration কী

Continuous Integration (CI) হল একটি ডেভেলপমেন্ট পদ্ধতি যা একাধিক অবদানকারীর কাছ থেকে কোডকে একটি একক কোডবেসে ইন্টিগ্রেট করার প্রক্রিয়াকে স্বয়ংক্রিয় করে। শব্দটি Martin Fowler 2000-এর দশকের শুরুর দিকে “ইন্টিগ্রেশন হেল” প্রতিরোধ করার জন্য অনুশীলনের একটি সেট হিসাবে প্রবর্তন করেছিলেন — এমন একটি পরিস্থিতি যেখানে ডেভেলপাররা সপ্তাহের পর সপ্তাহ বিচ্ছিন্নভাবে কাজ করে এবং পরিবর্তনগুলি মার্জ করার সময় অসংখ্য দ্বন্দ্ব দেখা দেয় যা সমাধান করতে দিন লাগে।

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 সহ ইউনিট টেস্ট, debug এবং release 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-এর আগে চালান।