Kotlin प्रोजेक्ट्स के लिए CI/CD: GitHub Actions A से Z तक

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

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

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

1. GitHub Actions और Kotlin की मूल बातें

GitHub Actions वर्कफ़्लो (workflow) पर आधारित है - YAML फ़ाइलें जो चरणों के अनुक्रम को परिभाषित करती हैं। प्रत्येक वर्कफ़्लो एक ट्रिगर (push, pull request, schedule) पर चलता है और एक वर्चुअल runner वातावरण में निष्पादित होता है।

Kotlin प्रोजेक्ट्स के लिए मानक स्टैक में शामिल हैं:

\n
• Gradle या Maven — बिल्ड सिस्टम;
\n
• JUnit / Kotest — टेस्टिंग फ्रेमवर्क;
\n
• Detekt / ktlint — Kotlin के लिए लिंटर।
\n

पहला कदम रिपॉजिटरी की रूट में .github/workflows/ci.yml फ़ाइल बनाना है। आइए बिल्ड और टेस्टिंग के लिए न्यूनतम कॉन्फ़िगरेशन देखें।

1.1 बेसिक बिल्ड और टेस्टिंग

आइए एक सरल पाइपलाइन से शुरू करें जो main ब्रांच पर प्रत्येक push और pull request पर चलती है:

name: CI for Kotlin\n\non:\n  push:\n    branches: [ main ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n\n    steps:\n      - uses: actions/checkout@v3\n      - name: Set up JDK 17\n        uses: actions/setup-java@v3\n        with:\n          java-version: '17'\n          distribution: 'temurin'\n      - name: Grant execute permission for gradlew\n        run: chmod +x gradlew\n      - name: Build with Gradle\n        run: ./gradlew build\n      - name: Run tests\n        run: ./gradlew test

यह कोड निम्न कार्य करता है: रिपॉजिटरी को क्लोन करता है, JDK 17 (Kotlin 1.9+ के लिए अनुशंसित संस्करण) सेट करता है, gradlew को निष्पादन योग्य बनाता है, बिल्ड करता है और टेस्ट चलाता है। यदि टेस्ट विफल होते हैं - पाइपलाइन त्रुटि के साथ रुक जाती है।

2. उन्नत कॉन्फ़िगरेशन: लिंटिंग, कैशिंग और मैट्रिक्स बिल्ड

बेसिक सेटअप अच्छा है, लेकिन वास्तविक प्रोजेक्ट के लिए और अधिक की आवश्यकता होती है। आइए Detekt के साथ कोड स्टाइल जांच और काम को गति देने के लिए Gradle डिपेंडेंसी कैशिंग जोड़ें।

2.1 Gradle कैशिंग

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

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

2.2 Detekt के साथ लिंटिंग

कोड जांच के लिए एक कार्य जोड़ें। Detekt को Gradle plugin के माध्यम से चलाया जा सकता है:

- name: Run Detekt\n  run: ./gradlew detekt

यदि Detekt उल्लंघन पाता है - पाइपलाइन त्रुटि के साथ समाप्त हो जाएगी। यह सुनिश्चित करता है कि रिपॉजिटरी में "गंदा" कोड न जाए।

2.3 मैट्रिक्स बिल्ड (Matrix Build)

यदि आपका प्रोजेक्ट Kotlin या JDK के कई संस्करणों का समर्थन करता है, तो मैट्रिक्स का उपयोग करें। यह कोड को डुप्लिकेट किए बिना संगतता की जांच करने की अनुमति देता है:

jobs:\n  build:\n    strategy:\n      matrix:\n        java: [11, 17, 21]\n        kotlin: [1.9.0, 2.0.0]\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v3\n      - name: Set up JD