GitLab CI: पाइपलाइन और सतत एकीकरण

GitLab CI क्या है?

GitLab CI एकीकृत DevSecOps GitLab एप्लिकेशन का हिस्सा है, जिसमें सतत एकीकरण, वितरण और डिप्लॉयमेंट शामिल है। यह प्रणाली 2012 में एक अलग प्रोजेक्ट के रूप में शुरू हुई लेकिन बाद में सीधे GitLab में एकीकृत हो गई। मूल सिद्धांत रिपॉजिटरी रूट में .gitlab-ci.yml फ़ाइल के माध्यम से कोड के रूप में कॉन्फ़िगरेशन है। 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