Swift के लिए CI/CD पाइपलाइन: macOS और Linux पर शुरू से सेटअप

आपका Swift प्रोजेक्ट ऑटोमेटिक डिप्लॉयमेंट का हकदार है: शुरू से CI/CD बनाएं

आपने एक शानदार Swift पैकेज या ऐप लिखा है। कोड शानदार चल रहा है, टेस्ट लोकली पास हो रहे हैं, आपको लगता है कि आप रॉक स्टार हैं। लेकिन जैसे ही आप push करते हैं — अफरा-तफरी शुरू हो जाती है: "क्या यह Linux पर बिल्ड होगा?", "क्या macOS पर टेस्ट पास होंगे?", "क्या मैं SwiftLint चलाना भूल गया?"।

परिचित लग रहा है? अगर हाँ, तो आपको Swift के लिए CI/CD पाइपलाइन चाहिए। यह आपके कोड के लिए ऑटोपायलट की तरह है: यह खुद बिल्ड करता है, टेस्ट करता है, स्टाइल चेक करता है और डिप्लॉय भी करता है। इस लेख में हम GitHub Actions के उदाहरण के साथ शुरू से Swift CI/CD पाइपलाइन सेटअप करेंगे। आपको तैयार काम करने वाला कोड मिलेगा जिसे आप आज ही कॉपी करके इस्तेमाल कर सकते हैं।

स्पॉयलर: सेटअप के बाद, आपको हर commit पर हरे निशान मिलेंगे, कंसोल पर बैठकर पसीना नहीं बहाना पड़ेगा।

Swift के लिए CI/CD क्यों ज़रूरी है, विलासिता नहीं

Swift दो दुनियाओं में रहता है: macOS (Xcode, CocoaPods, Carthage) और Linux (Vapor, SwiftNIO, सर्वर प्रोजेक्ट)। CI/CD के बिना, आप जोखिम उठाते हैं:

\n
• दूसरे प्लेटफॉर्म पर कंपाइलेशन एरर को मिस करना
\n
• लिंटर चलाना भूल जाना (और फिर कोड बमबारी के बाद जैसा दिखता है)
\n
• मैन्युअल डिप्लॉयमेंट में घंटों बर्बाद करना
\n
• रीग्रेशन ढूंढने में समय गंवाना
\n

सही तरीके से सेटअप की गई Swift CI/CD पाइपलाइन इन सभी समस्याओं को हल करती है। यह 24/7 काम करती है, कॉफी नहीं पीती और यह नहीं कहती "मेरे पास तो सब काम कर रहा है"। चलिए शुरू करते हैं!

चरण 1: टूल चुनें — GitHub Actions

हम GitHub Actions का उपयोग करेंगे — यह GitHub में बिल्ट-इन CI/CD है, और Swift के लिए यह आदर्श है। कारण:

\n
• मुफ्त पब्लिक रिपॉजिटरी के लिए (महीने में 2000 मिनट)
\n
• macOS रनर — Xcode के तहत बिल्ड कर सकते हैं
\n
• Linux रनर — सर्वर-साइड Swift प्रोजेक्ट के लिए
\n
• तैयार actions SwiftLint, टेस्ट, डिप्लॉय के लिए
\n

अगर आप GitLab, Bitbucket या Jenkins का उपयोग करते हैं — सिद्धांत समान हैं, लेकिन YAML सिंटैक्स अलग होगा।

चरण 2: Swift CI/CD पाइपलाइन की बुनियादी संरचना

किसी भी पाइपलाइन में तीन चरण होते हैं:

\n
1. Build — प्रोजेक्ट बिल्ड करना (SPM या Xcode)
\n
2. Test — Unit-टेस्ट चलाना
\n
3. Lint — कोड स्टाइल की जांच (वैकल्पिक, लेकिन अत्यधिक अनुशंसित)
\n

अतिरिक्त रूप से डिप्लॉय (जैसे, सर्वर या TestFlight पर) जोड़ा जा सकता है।

फ़ाइल बनाएं .github/workflows/swift-ci.yml

अपने रिपॉजिटरी की रूट में .github/workflows/ फ़ोल्डर बनाएं और उसके अंदर swift-ci.yml फ़ाइल बनाएं। यहाँ न्यूनतम काम करने वाली पाइपलाइन है:

name: Swift CI/CD Pipeline\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n\n    steps:\n    - name: Checkout code\n      uses: actions/checkout@v3\n\n    - name: Setup Swift\n      uses: swift-actions/setup-swift@v1\n      with:\n        swift-version: "5.9"\n\n    - name: Build\n      run: swift build\n\n    - name: Run tests\n      run: swift test

यह Swift CI/CD पाइपलाइन हर push या pull request पर main/develop में चलती है। यह प्रोजेक्ट बिल्ड करती है और Ubuntu पर टेस्ट चलाती है। सरल? हाँ। लेकिन चलिए इसमें जादू जोड़ते हैं।

चरण 3: बिल्ड मैट्रिक्स में macOS और Xcode जोड़ें

Swift डेवलपर अक्सर macOS पर काम करते हैं, जबकि सर्वर साइड Linux पर होती है। यह सुनिश्चित करने के लिए कि प्रोजेक्ट हर जगह बिल्ड हो, हम मैट्रिक्स स्ट्रेटेजी का उपयोग करते हैं:

jobs:\n  build-and-test:\n    strategy:\n      matrix:\n        os: [ubuntu-latest, macos-latest]\n        swift-version: ["5.8", "5.9"]\n\n    runs-on: ${{ matrix.os }}\n\n    steps:\n    - uses: actions/checkout@v3\n\n    - name: Setup Swift\n      uses: swift-actions/setup-swift@v1\n