GitHub Actions पर Kotlin प्रोजेक्ट्स के लिए CI/CD: एक संपूर्ण गाइड

शुरुआती लोगों के लिए ऑनलाइन Python प्रशिक्षक

Python आसानी से सीखें बिना सिद्धांत के बोझ के। स्वचालित जांच के साथ व्यावहारिक कार्य हल करें और ब्राउज़र में सीधे कोड लिखें।

पाठ्यक्रम शुरू करें

परिचय: Kotlin प्रोजेक्ट्स के लिए CI/CD क्यों महत्वपूर्ण है

Kotlin में आधुनिक डेवलपमेंट - चाहे वह Spring Boot पर बैकएंड हो, Android ऐप हो या मल्टीप्लेटफ़ॉर्म प्रोजेक्ट - के लिए तेज़ और विश्वसनीय डिलीवरी चक्र की आवश्यकता होती है। मैन्युअल बिल्ड और टेस्टिंग प्रक्रियाएं न केवल समय लेती हैं, बल्कि त्रुटियों का कारण भी बन सकती हैं। यहाँ CI/CD (Continuous Integration / Continuous Deployment) मददगार साबित होता है।

GitHub Actions एक अंतर्निहित ऑटोमेशन सिस्टम है जो आपको अपने रिपॉजिटरी में सीधे वर्कफ़्लो (workflows) चलाने की अनुमति देता है। Kotlin प्रोजेक्ट्स के लिए यह एक आदर्श विकल्प है: यह Gradle के साथ आसानी से एकीकृत होता है, डिपेंडेंसी कैशिंग को सपोर्ट करता है और आपको किसी भी प्लेटफ़ॉर्म पर ऐप्लिकेशन डिप्लॉय करने देता है।

इस लेख में, हम GitHub Actions का उपयोग करके Kotlin प्रोजेक्ट के लिए एक पूर्ण CI/CD पाइपलाइन सेट अप करने का तरीका समझेंगे: बेसिक बिल्ड से लेकर ऑटोमैटिक डिप्लॉयमेंट तक।

1. GitHub Actions की मूल बातें: workflow की संरचना

GitHub Actions में प्रत्येक workflow एक YAML फ़ाइल है जो .github/workflows/ डायरेक्टरी में स्थित होती है। आइए Kotlin प्रोजेक्ट के उदाहरण के साथ बुनियादी घटकों को समझें।

1.1. ट्रिगर (on)

Workflow विशिष्ट घटनाओं पर चलता है: ब्रांच में push, Pull Request बनाना, या शेड्यूल (cron) के अनुसार।

1.2. Jobs और Steps

Job, एक वर्चुअल एनवायरनमेंट पर निष्पादित चरणों का एक सेट है। Steps कमांड, स्क्रिप्ट या मार्केटप्लेस से तैयार actions चला सकते हैं।

1.3. न्यूनतम workflow का उदाहरण

Gradle पर Kotlin प्रोजेक्ट के लिए .github/workflows/ci.yml फ़ाइल बनाएँ:

name: CI for Kotlin

on:  push:    branches: [ main, develop ]  pull_request:    branches: [ main ]

jobs:  build:    runs-on: ubuntu-latest

    steps:      - uses: actions/checkout@v4

      - name: Set up JDK 17        uses: actions/setup-java@v4        with:          java-version: '17'          distribution: 'temurin'

      - name: Setup Gradle        uses: gradle/actions/setup-gradle@v3

      - name: Build with Gradle        run: ./gradlew build

      - name: Run tests        run: ./gradlew test

यह पाइपलाइन main/develop में प्रत्येक push या PR पर बिल्ड और टेस्ट चलाएगी।

2. CI का ऑप्टिमाइज़ेशन: कैशिंग और समानांतर कार्य

ऑप्टिमाइज़ेशन के बिना, प्रत्येक रन Gradle डिपेंडेंसी को फिर से डाउनलोड करेगा। Kotlin प्रोजेक्ट्स के लिए इसमें 2-5 मिनट लग सकते हैं। समाधान है कैशिंग।

2.1. Gradle कैश को कैश करना

GitHub Actions ~/.gradle/caches डायरेक्टरी को कैश करने की अनुमति देता है:

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

पहले रन के बाद, बाद के रन कैश का उपयोग करेंगे - गति 2-3 गुना बढ़ जाती है।

2.2. विभिन्न कार्यों के लिए समानांतर jobs

टेस्टिंग, लिंटिंग और बिल्ड को अलग-अलग jobs में विभाजित किया जा सकता है जो समानांतर रूप से चलती हैं:

jobs:  lint:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Run detekt        run: ./gradlew detekt

  test:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Run tests        run: ./gradlew test

  build:    needs: [lint, test]    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - name: Build JAR        run: ./gradlew bootJar

यहाँ, build लिंटिंग और टेस्ट सफलतापूर्वक पास होने के बाद ही चलेगा।