GitLab CI: পাইপলাইন এবং ক্রমাগত ইন্টিগ্রেশন

GitLab CI কী?

GitLab CI হল একীভূত DevSecOps GitLab অ্যাপ্লিকেশনের অংশ, যার মধ্যে ক্রমাগত ইন্টিগ্রেশন, ডেলিভারি এবং ডিপ্লয়মেন্ট অন্তর্ভুক্ত। সিস্টেমটি 2012 সালে একটি পৃথক প্রকল্প হিসেবে শুরু হয়েছিল কিন্তু পরে সরাসরি GitLab-এ একীভূত হয়। মূল নীতি হল রিপোজিটরি রুটে .gitlab-ci.yml ফাইলের মাধ্যমে কোড হিসাবে কনফিগারেশন (Configuration as Code)। 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-তে গ্লোবালি, কনফিগারেশন ফাইলে, গ্রুপ এবং প্রকল্প সেটিংসে। ভেরিয়েবলের অগ্রাধিকার একটি শ্রেণিবিন্যাস অনুসরণ করে: ট্রিগার ভেরিয়েবলের সর্বোচ্চ অগ্রাধিকার, তারপর 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 (Static Application Security Testing)-ও রয়েছে।

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 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