Kotlin प्रोजेक्ट्स के लिए GitHub Actions के साथ CI/CD: चरण-दर-चरण मार्गदर्शिका

परिचय: Kotlin विकास के लिए CI/CD क्यों अपरिहार्य है

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

GitHub Actions CI/CD को लागू करने के लिए सबसे लोकप्रिय टूल में से एक है, खासकर यदि आपका कोड पहले से GitHub पर संग्रहीत है। यह Kotlin इकोसिस्टम के साथ गहराई से एकीकृत होता है, Gradle और Maven का समर्थन करता है, और आपको किसी भी आवश्यकता के अनुसार पाइपलाइनों को लचीले ढंग से कॉन्फ़िगर करने की अनुमति देता है। इस लेख में, हम GitHub Actions का उपयोग करके Kotlin प्रोजेक्ट के लिए बिल्ड, टेस्टिंग और डिप्लॉयमेंट का पूरा चक्र स्थापित करने का तरीका जानेंगे।

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

कोड लिखने से पहले, आइए बुनियादी अवधारणाओं को समझें। GitHub Actions में Workflow एक स्वचालित प्रक्रिया है जो एक विशिष्ट घटना (जैसे, main ब्रांच में push) पर ट्रिगर होती है। Workflow को YAML फ़ाइल में वर्णित किया जाता है, जो आपके रिपॉजिटरी की .github/workflows/ निर्देशिका में संग्रहीत होती है।

एक सामान्य Workflow संरचना में शामिल है:

• name — Workflow का नाम (GitHub इंटरफ़ेस में प्रदर्शित होता है)।
• on — ट्रिगर (उदाहरण के लिए, push, pull_request)।
• jobs — कार्यों का सेट जो क्रमिक या समानांतर रूप से निष्पादित होते हैं।
• steps — job के अंदर चरण (JDK सेट करना, डिपेंडेंसी कैश करना, टेस्ट चलाना)।

Kotlin प्रोजेक्ट्स के लिए, मुख्य कदम JDK के सही संस्करण (आमतौर पर 11, 17 या 21) को कॉन्फ़िगर करना और Gradle Wrapper (./gradlew) का उपयोग करना है, जो किसी भी मशीन पर बिल्ड की पुनरुत्पादकता सुनिश्चित करता है।

चरण 1: Kotlin प्रोजेक्ट का बुनियादी बिल्ड और टेस्टिंग

चलिए सबसे सरल से शुरू करते हैं: एक Workflow जो main में प्रत्येक push या Pull Request बनाने पर टेस्ट चलाएगा। यह किसी भी CI/CD का आधार है — यह सुनिश्चित करना कि कोड मौजूदा कार्यक्षमता को न तोड़े।

निम्नलिखित सामग्री के साथ एक फ़ाइल .github/workflows/ci.yml बनाएँ:

name: CI for Kotlin

on:  push:    branches: [ main ]  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: Grant execute permission for gradlew        run: chmod +x gradlew

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

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

      - name: Run tests        run: ./gradlew test

आइए मुख्य बिंदुओं को समझें:

• actions/checkout@v4 — रिपॉजिटरी को runner में क्लोन करता है।
• actions/setup-java@v4 — JDK 17 (Temurin) स्थापित करता है। यदि आपके प्रोजेक्ट को JDK 11 या 21 जैसे किसी अन्य संस्करण की आवश्यकता है, तो आप कोई दूसरा संस्करण चुन सकते हैं।
• actions/cache@v4 — Gradle डिपेंडेंसी को कैश करता है। यह गति के लिए महत्वपूर्ण है: कैश के बिना, प्रत्येक बिल्ड सभी लाइब्रेरी को फिर से डाउनलोड करेगा (जिसमें 2-5 मिनट लग सकते हैं)। कैश इस प्रक्रिया को कुछ सेकंड तक तेज कर देता है।
• ./gradlew build — प्रोजेक्ट का पूर्ण बिल्ड (कंपाइलेशन + टेस्ट)। यदि आप केवल टेस्ट चाहते हैं, तो ./gradlew test का उपयोग करें।
```