आपकी टीम में फ्रंटएंड की pull request पर CI में कौन सी जांचें चलती हैं, और असल में merge कौन सी रोकती हैं?

आम तौर पर रोकने वाली जांचें हैं type checking, lint, unit तथा component tests, एक प्रोडक्शन build और bundle size का बजट। एक्सेसिबिलिटी scans और end to end tests भी pull request पर चलते हैं, पर सिर्फ अहम यात्राओं पर रोकते हैं। सलाहकार किस्म की चीज़ें, जैसे Lighthouse स्कोर या visual diffs, बिना रोके रिपोर्ट करती हैं, क्योंकि जो gate ऐसी वजहों से फेल हो जिन पर लेखक का बस नहीं, वह महीने भर में बंद कर दिया जाता है।

रोकने वाली जांचों में मुझे चाहिए type check, lint, unit तथा component suite, एक असली प्रोडक्शन build और bundle size का बजट। ये तय नतीजे देते हैं, ऐसी वजहों से फेल होते हैं जिन्हें लेखक ठीक कर सकता है, और तेज़ हैं। end to end tests pull request पर चलते हैं पर मैं सिर्फ छोटे critical path वाले suite पर रोकता हूं, बाकी merge पर चलते हैं, वरना कतार ही अड़चन बन जाती है और लोग लाल पर merge करने लगते हैं। सलाहकार के तौर पर हम Lighthouse का run और visual diff एक comment की तरह डालते हैं। मैं जानबूझकर परफॉर्मेंस स्कोर पर नहीं रोकता क्योंकि वह runner के शोर के साथ हिलता है, और चंचल gate को दरकिनार किया जाता है और फिर नज़रअंदाज़। हर pull request को एक preview deploy भी मिलता है, और डिज़ाइनर तथा प्रोडक्ट असल में वही देखते हैं, और वही उस श्रेणी के bugs पकड़ता है जो सिर्फ असली build में दिखते हैं, जैसे कोई environment variable जो development के बाहर कभी सेट ही नहीं हुआ। जिस gate को लोग कम आंकते हैं वह size बजट है: यही अकेली चीज़ है जो bundle को एक एक dependency करके ऊपर सरकने से रोकती है।