गाइड

अपनी मशीन पर iOS CI/CD पाइपलाइन चलाना

iOS CI की ज़्यादातर सलाह गलत चीज़ को ऑप्टिमाइज़ करती है। मिनट शायद ही कभी बिल्ड स्टेप में जाते हैं। असली पाइपलाइन पर असल फ़र्क किस चीज़ से पड़ता है, यह पेज वही बताता है। साथ ही यह भी कि डेडिकेटेड हार्डवेयर हिसाब कैसे बदलता है।

मिनट असल में कहाँ जाते हैं

होस्टेड रनर पर आम iOS जॉब का बड़ा हिस्सा आपके कोड की पहली लाइन कंपाइल होने से पहले ही निकल जाता है। डिपेंडेंसी रिज़ॉल्व और डाउनलोड होती हैं। खाली DerivedData फ़ोल्डर वॉर्म होता है। टूल इंस्टॉल होते हैं और सिम्युलेटर बूट होता है। यह काम हर रन पर दोहराया जाता है, क्योंकि बाद में मशीन मिटा दी जाती है।

डेडिकेटेड मशीन पर यह काम ज़्यादातर पहले से हो चुका होता है। Wikipedia iOS ऐप पर हमारे बेंचमार्क में M6 mini पर क्लीन बिल्ड GitHub के स्टैंडर्ड रनर से 53 प्रतिशत तेज़ था। आम CI जॉब 269 सेकंड से घटकर 27 सेकंड का रह गया। वजह यह थी कि डेडिकेटेड Mac ने अपना बिल्ड फ़ोल्डर रखा और सिर्फ़ बदला हुआ हिस्सा फिर बनाया।

कॉपी करने लायक पाइपलाइन

काम बाँटें। लिंट, शेयर्ड Swift पैकेज के टेस्ट और रिलीज़ ऑटोमेशन Linux पर चल सकते हैं। Mac पर सिर्फ़ सिम्युलेटर और डिवाइस का काम रखें।
सही पाथ कैश करें। DerivedData, SwiftPM, CocoaPods और Gems। डेडिकेटेड मशीन पर ये बिना किसी खर्च के बने रहते हैं।
उबाऊ हिस्सों के लिए fastlane इस्तेमाल करें। बिल्ड, टेस्ट, स्क्रीनशॉट और अपलोड की lanes से लोकल और CI पर एक जैसे कमांड मिलते हैं।
साइनिंग को अनुमान लायक रखें। प्राइवेट सर्टिफ़िकेट रिपॉज़िटरी के साथ fastlane match अब भी सबसे भरोसेमंद तरीका है। MacRun आपकी साइनिंग मैनेज नहीं करता। इसका मतलब है कि वहाँ आपको कोई सरप्राइज़ भी नहीं मिलता।
मैट्रिक्स छोटा करें। पूरे डिवाइस और OS मैट्रिक्स main और रात के रन के लिए हैं, हर पुल रिक्वेस्ट के लिए नहीं।

उदाहरण वर्कफ़्लो

name: iOS
on: [pull_request]

jobs:
  test:
    runs-on: [self-hosted, macOS, macrun-unit-01]
    steps:
      - uses: actions/checkout@v4
      - run: sudo xcodes select 26.6
      - run: bundle install
      - run: bundle exec fastlane test

रनर डेडिकेटेड है, इसलिए यहाँ कैश रिस्टोर का कोई स्टेप नहीं है। पिछले रन की डिपेंडेंसी और DerivedData पहले से डिस्क पर हैं।

इससे क्या हल नहीं होता

डेडिकेटेड हार्डवेयर धीमा टेस्ट सूट ठीक नहीं करता। न ही वह मॉड्यूल ग्राफ़ ठीक करता है जो पूरे रीबिल्ड पर मजबूर करे, या अस्थिर सिम्युलेटर टेस्ट। यह बार-बार के सेटअप का बोझ और प्रति मिनट का मीटर हटाता है। बाकी अब भी आपकी तरफ़ का इंजीनियरिंग काम है।

अक्सर पूछे जाने वाले सवाल

GitHub Actions में iOS बिल्ड तेज़ कैसे करूँ?

कंपाइलेशन ऑप्टिमाइज़ करने से पहले बार-बार का सेटअप घटाएँ। DerivedData, SwiftPM और CocoaPods के कैश बनाए रखें। जो काम Mac का नहीं, उसे Linux रनर पर ले जाएँ। पुल रिक्वेस्ट पर डिवाइस मैट्रिक्स छोटा करें, और एक Xcode वर्ज़न पिन करें। डेडिकेटेड हार्डवेयर पर कैश रन के बीच अपने आप बने रहते हैं।

क्या मैं self-hosted macOS रनर पर fastlane इस्तेमाल कर सकता हूँ?

हाँ। MacRun मशीनों पर fastlane, CocoaPods, Ruby और Node पहले से इंस्टॉल हैं। आप उन्हें ठीक वैसे ही चलाते हैं जैसे लोकल पर। fastlane match से साइनिंग किसी भी Mac की तरह ही काम करती है।

क्या MacRun मेरे लिए कोड साइनिंग संभालता है?

नहीं, और यह जानबूझकर है। आपके सर्टिफ़िकेट और प्रोविज़निंग प्रोफ़ाइल आपके कंट्रोल में रहते हैं, आम तौर पर आपकी अपनी प्राइवेट रिपॉज़िटरी के साथ fastlane match से। हम मशीन देते हैं, मैनेज्ड साइनिंग सर्विस नहीं।

क्या मैं डेडिकेटेड रनर पर iOS UI टेस्ट चला सकता हूँ?

हाँ। सिम्युलेटर सामान्य रूप से चलते हैं। मशीन रीसायकल नहीं होती, इसलिए सिम्युलेटर की बूट स्थिति और derived data रन के बीच वॉर्म रहते हैं। इससे UI टेस्ट जॉब से आम तौर पर कई मिनट कम हो जाते हैं।