GitHub Actions — यह क्या है, CI/CD पाइपलाइन और ऑटोमेशन

GitHub Actions क्या है?

GitHub Actions GitHub में निर्मित एक वर्कफ़्लो ऑटोमेशन प्लेटफ़ॉर्म है जिसे 2019 में लॉन्च किया गया था। यह आपको YAML फ़ाइलों में CI/CD पाइपलाइन को परिभाषित करने की अनुमति देता है जो सीधे रिपॉजिटरी में संग्रहीत होती हैं। प्रत्येक workflow एक ट्रिगर द्वारा सक्रिय होता है: push, pull request, टैग निर्माण या शेड्यूल के अनुसार। Jenkins या TeamCity के विपरीत, CI सर्वर होस्ट करने के लिए अलग बुनियादी ढाँचे की आवश्यकता नहीं होती है।

मोबाइल डेवलपमेंट के संदर्भ में, GitHub Actions APK और IPA बिल्ड, इम्यूलेटर पर यूनिट टेस्ट और UI टेस्ट चलाने, लिंटर्स द्वारा कोड जाँच, हस्ताक्षर और Google Play और App Store में प्रकाशन को ऑटोमेट करता है। प्लेटफ़ॉर्म मुफ्त मिनट प्रदान करता है सार्वजनिक रिपॉजिटरी के लिए और निजी के लिए मूल्य योजना के अनुसार। ओपन-सोर्स मोबाइल प्रोजेक्ट्स के लिए, यह बिना लागत के एक पूर्ण CI/CD समाधान है।

GitHub Actions की आर्किटेक्चर: Workflows, Jobs और Steps

GitHub Actions की आर्किटेक्चर चार स्तरों से बनी है। Workflow मूल YAML फ़ाइल है जो ऑटोमेशन को परिभाषित करती है। Workflow Jobs से बना होता है, प्रत्येक Job एक अलग Runner पर चलता है। Job के अंदर Steps निष्पादित होते हैं — अनुक्रमिक कमांड या बाहरी actions। Events ट्रिगर को परिभाषित करते हैं: push, pull_request, schedule, workflow_dispatch। GitHub इंटरफ़ेस में Actions टैब के माध्यम से workflow को मैन्युअल रूप से भी ट्रिगर किया जा सकता है।

GitHub पूर्व-स्थापित OS के साथ होस्ट किए गए runners प्रदान करता है: Ubuntu, macOS और Windows। iOS बिल्ड के लिए macOS-runner अनिवार्य है, Android के लिए — Linux या macOS। Self-hosted runners आपको कस्टम वातावरण के साथ अपने स्वयं के सर्वर पर jobs चलाने की अनुमति देते हैं, जो विशेष हार्डवेयर आवश्यकताओं वाले बड़े प्रोजेक्ट्स के लिए उपयोगी है। GitHub jobs निष्पादन कतारों को व्यवस्थित करने के लिए self-hosted runner समूहों का भी समर्थन करता है।

Workflow फ़ाइल की संरचना

मूल workflow फ़ाइल में अनुभाग होते हैं: name, on (ट्रिगर), jobs। प्रत्येक job runs-on (runner प्रकार), strategy (मैट्रिक्स), steps (क्रियाओं की सूची) निर्दिष्ट करता है। Steps शेल कमांड या मार्केटप्लेस से तैयार actions हो सकते हैं, जो owner/repo@version सिंटैक्स के माध्यम से जुड़े होते हैं।

GitHub Actions में मोबाइल एप्लिकेशन का बिल्ड

Android बिल्ड के लिए, workflow में आमतौर पर चरण शामिल होते हैं: रिपॉजिटरी का checkout, JDK स्थापना, Gradle कैश कॉन्फ़िगरेशन, assembleRelease चलाना। iOS के लिए macOS-runner आवश्यक है, xcode-select के माध्यम से Xcode स्थापना, provisioning profile समाधान और xcodebuild चलाना। iOS बिल्ड की जटिलता code signing और प्रमाणपत्र प्रबंधन में निहित है। Apple-विशिष्ट सेटिंग्स में apple-actions/import-codesign-certs के माध्यम से provisioning profile प्रबंधन शामिल है।

Matrix strategy एक साथ कई संस्करणों पर बिल्ड चलाने की अनुमति देती है। उदाहरण के लिए: iOS संस्करणों (15.0, 16.0, 17.0) और Xcode (14, 15) के साथ मैट्रिक्स। यह सत्यापन को गति देता है विभिन्न OS संस्करणों के साथ एप्लिकेशन संगतता का, हालाँकि यह runner मिनटों की खपत बढ़ाता है। सीमित CI बजट वाले प्रोजेक्ट्स के लिए, मैट्रिक्स को केवल मुख्य कॉन्फ़िगरेशन तक सीमित किया जा सकता है।

Android के लिए वातावरण सेट अप करना

GitHub Actions JDK स्थापना के लिए setup-java action और Gradle कैशिंग के लिए caching प्रदान करता है। Android SDK Ubuntu runners पर पहले से स्थापित है। कस्टम API स्तरों के लिए, एक अलग चरण में sdkmanager का उपयोग किया जाता है। Android और iOS बिल्ड के लिए अलग-अलग workflows बनाने की अनुशंसा की जाती है, क्योंकि वे विभिन्न runners और बिल्ड टूल का उपयोग करते हैं।

GitHub Marketplace और तैयार actions

GitHub Marketplace में समुदाय और आधिकारिक डेवलपर्स द्वारा बनाए गए 15,000 से अधिक actions शामिल हैं। मोबाइल डेवलपमेंट के लिए, मुख्य श्रेणियों में शामिल हैं: Code signing (apple-actions/import-codesign-certs), परीक्षण (react-native-community/action), डिप्लॉयमेंट (google-github-actions/release-google-play), सूचनाएँ (slackapi/slack-github-action)। Firebase App Distribution, TestFlight अपलोड और Fastlane के लिए भी actions उपलब्ध हैं। प्रत्येक action में एक विशिष्ट runner OS के लिए संगतता लेबल होता है।

प्रत्येक action में एक संस्करण, विवरण, README और लाइसेंस होता है। action चुनते समय, विक्रेताओं (Google, Apple, Microsoft) से आधिकारिक और Verified Badge के माध्यम से सत्यापित को प्राथमिकता दी जानी चाहिए। एक निश्चित प्रमुख संस्करण निर्दिष्ट करना महत्वपूर्ण है (actions/checkout@v4), @main नहीं, अप्रत्याशित परिवर्तनों से बचने के लिए। यदि आवश्यक action Marketplace में नहीं है, तो आप एक कस्टम action बना सकते हैं — स्थानीय रूप से रिपॉजिटरी में (Docker action या JavaScript action) या Marketplace में प्रकाशित कर सकते हैं।

मोबाइल CI/CD के लिए लोकप्रिय actions

• actions/checkout — रिपॉजिटरी को runner में क्लोन करता है
• actions/setup-java — Android बिल्ड के लिए JDK स्थापित करता है
• gradle/actions/setup-gradle — Gradle को कॉन्फ़िगर और कैश करता है
• apple-actions/import-codesign-certs — iOS के लिए प्रमाणपत्र आयात करता है
• google-github-actions/submit-release — Google Play Console में प्रकाशित करता है

iOS प्रोजेक्ट के लिए workflow का उदाहरण

iOS एप्लिकेशन विकसित करते समय, सिम्युलेटर और उपकरणों के साथ सही कार्य सेट अप करना महत्वपूर्ण है। macOS-14 runner ARM आर्किटेक्चर पर Intel बिल्ड चलाने के लिए Rosetta 2 के साथ वातावरण प्रदान करता है। एक workflow में कई बिल्ड स्कीम शामिल हो सकती हैं — pull request के लिए Debug और टैग के लिए Release। GitHub Actions परीक्षण परिणाम प्रदर्शित करने के लिए xcparse/sonarqube action के माध्यम से xcresult पार्सिंग का समर्थन करता है। बिल्ड स्थिति सूचनाएँ भेजने के लिए, Slack या Telegram action जोड़ा जा सकता है।

iOS के लिए Code signing में प्रमाणपत्र और provisioning profiles आयात करना शामिल है। Apple-actions प्रदान करते हैं P12 प्रमाणपत्र आयात करने और provisioning profile स्थापित करने के लिए एक चरण। प्रमाणपत्र GitHub Actions secrets के रूप में संग्रहीत होते हैं और केवल बिल्ड चरण में डिक्रिप्ट किए जाते हैं। हस्ताक्षर ऑटोमेशन के लिए Fastlane match का उपयोग किया जाता है, जिसे workflow में एक अलग चरण के रूप में कॉल किया जा सकता है।

आइए Swift में iOS ऐप के लिए एक workflow पर विचार करें जो प्रोजेक्ट बनाता है, परीक्षण चलाता है और एक आर्काइव किया गया बिल्ड बनाता है। Workflow उपयोग करता है macOS-14 runner, Xcode 15.4 और प्रमाणपत्र प्रबंधन के लिए actions।

name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

GitHub Actions में डिपेंडेंसी कैशिंग

कैशिंग workflow रन के बीच डिपेंडेंसी को संरक्षित करके बिल्ड समय को कम करता है। GitHub प्रदान करता है actions/cache के माध्यम से अंतर्निर्मित कैशिंग। Gradle के लिए, ~/.gradle कैश किया जाता है, CocoaPods के लिए — Pods/, SPM के लिए — .build/। कैश कुंजी में डिपेंडेंसी सूची फ़ाइल का हैश शामिल होता है — जब डिपेंडेंसी बदलती हैं, तो कैश स्वचालित रूप से अमान्य हो जाता है।

कैश पुनर्स्थापना रणनीति (restore-keys) पर विशेष ध्यान दिया जाना चाहिए। यदि सटीक कुंजी नहीं मिलती है, तो GitHub Actions restore-keys द्वारा आंशिक मिलान का प्रयास करता है। यह उपयोगी है जब केवल एक डिपेंडेंसी बदलती है — कैश आंशिक रूप से उपयोग योग्य रहता है। Gradle के लिए, Gradle Build Cache को सक्षम करने की अतिरिक्त अनुशंसा की जाती है, जो प्रोजेक्ट के विभिन्न मॉड्यूल के बीच बिल्ड परिणामों को कैश करता है।

Gradle कैशिंग का उदाहरण

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

कैश दक्षता Android प्रोजेक्ट्स के लिए: कैश के बिना पहला बिल्ड — 8–12 मिनट, कैश के साथ बाद का बिल्ड — 2–4 मिनट। CocoaPods के साथ iOS के लिए, बचत समान है। इष्टतम कैश प्रबंधन के लिए actions/cache को Gradle के setup-gradle action के साथ संयोजित करने की अनुशंसा की जाती है। React Native में npm डिपेंडेंसी के लिए, actions/cache का उपयोग package-lock.json हैशिंग के साथ किया जाता है। उचित कैश कॉन्फ़िगरेशन के साथ, बिल्ड समय को 70% तक कम किया जा सकता है।

GitHub Actions workflow, job और step स्तर पर पर्यावरण चर का समर्थन करता है। पर्यावरण चर को ओवरराइड किया जा सकता है: step-स्तर की सर्वोच्च प्राथमिकता होती है। गोपनीय डेटा के लिए, हमेशा secrets का उपयोग करें — वे AES-256 के साथ एन्क्रिप्टेड होते हैं और लॉग में प्रदर्शित नहीं होते हैं। पर्यावरण सुरक्षा नियम भी उपलब्ध हैं — डिप्लॉयमेंट से पहले अनिवार्य मैन्युअल अनुमोदन। अतिरिक्त सुरक्षा के लिए, विशिष्ट उपयोगकर्ताओं या टीमों से अनिवार्य अनुमोदन कॉन्फ़िगर किया जा सकता है।

GitHub Actions Reusable Workflows का भी समर्थन करता है — पुन: प्रयोज्य पाइपलाइन जिन्हें अन्य workflows से कॉल किया जा सकता है। यह अनुमति देता है एक केंद्रीकृत बिल्ड workflow बनाने और इसे संगठन के सभी रिपॉजिटरी में पुन: उपयोग करने की। Reusable workflow एक पंक्ति में कॉल किया जाता है और इनपुट पैरामीटर और secrets स्वीकार कर सकता है। यह बड़ी टीमों में CI/CD प्रथाओं को मानकीकृत करने के लिए विशेष रूप से उपयोगी है।

सुरक्षा और सर्वोत्तम अभ्यास

मोबाइल प्रोजेक्ट्स के लिए GitHub Actions कॉन्फ़िगर करते समय, सुरक्षा सिद्धांतों का पालन करना महत्वपूर्ण है। OIDC (OpenID Connect) आपको दीर्घकालिक क्रेडेंशियल्स को समाप्त करने और क्लाउड प्रदाताओं के लिए अस्थायी टोकन प्राप्त करने की अनुमति देता है। स्क्रिप्ट में कभी भी plain-text secrets का उपयोग न करें — GitHub Actions स्वचालित रूप से लॉग में secrets को मास्क करता है।

मोबाइल प्रोजेक्ट्स के लिए, तृतीय-पक्ष forks के लिए workflow पहुँच को प्रतिबंधित करना महत्वपूर्ण है। pull_request_target सेटिंग का उपयोग करें सावधानी के साथ — यह fork से नहीं, बल्कि आधार शाखा से कोड निष्पादित करता है। iOS ऐप्स के लिए code signing के लिए, प्रमाणपत्रों को एन्क्रिप्टेड रूप में संग्रहीत करने और उन्हें केवल बिल्ड चरण में gpg या openssl के माध्यम से डिक्रिप्ट करने की अनुशंसा की जाती है।