Config as code के साथ स्कीमा-आधारित फ़्लो
कॉन्फ़िगरेशन-संचालित UI प्लेटफ़ॉर्म और Git-आधारित config-as-code, ताकि नियम में बदलाव घंटों में बिना फ्रंटएंड डिप्लॉय के रिलीज़ हों।
- टेक स्टैक
- TypeScript · jsonform · Git · CI/CD · Schema validation
समस्या
कई बाज़ारों के फ़्लो का मतलब था दोहराया हुआ कोड और हर बार इंजीनियरिंग टिकट, जब भी प्रोडक्ट या कंप्लायंस किसी क्षेत्रीय नियम को बदलना चाहता था।
तरीका
- स्कीमा से फ़ॉर्म रेंडर करना। UI jsonform के ज़रिए JSON या YAML कॉन्फ़िगरेशन पढ़ता है: स्कीमा फ़ील्ड और वैलिडेशन नियम बनाता है। कस्टम क्रियाएँ, जैसे नेटिव ब्रिज शुरू करना, कोड में रहती हैं।
- एक चरण, अलग नतीजे। कॉन्फ़िगरेशन तय करता है कि हर बाज़ार और प्लेटफ़ॉर्म के लिए चरण क्या करे। जहाँ नेटिव क्षमता समर्थित है, वहाँ चरण मार्गदर्शन और स्कैन बटन दिखाता है; वरना सामान्य फ़ॉर्म फ़ील्ड और जारी रखें बटन। प्रोडक्ट टीम इसे कोड में नहीं, कॉन्फ़िगरेशन में बदलती है।
- कोड के रूप में कॉन्फ़िगरेशन। बदलाव Git के ज़रिए जमा होते हैं। हर बदलाव एक ऑटोमेटेड pull request खोलता है और TypeScript टाइप के सहारे सख़्त स्कीमा वैलिडेशन के साथ CI चलाता है, इसलिए गलत कॉन्फ़िगरेशन प्रोडक्शन से पहले ही फ़ेल हो जाता है।
दो फ़ैसले जिन्हें समझाना ज़रूरी है
रेंडरिंग के लिए jsonform, क्रियाओं के लिए कोड। पूरी तरह सर्वर-संचालित UI जो सर्वर से भेजा गया मनमाना लॉजिक चलाए, रिमोट कोड एक्ज़ीक्यूशन के जोखिम और परफ़ॉर्मेंस समस्याओं को न्योता देता है। डेटा-संचालित रेंडरिंग और पहले से कंपाइल हैंडलरों से बँधी क्रियाएँ उस जोखिम के बिना लचीलापन बनाए रखती हैं।
एडमिन फ़ॉर्म की जगह Git। शासन के बिना आसान एडिट प्रोडक्शन फ़्लो तोड़ देते हैं। Pull request, टाइप जाँच और CI हर बदलाव को जवाबदेह, समीक्षित और आसानी से वापस लिए जा सकने वाला बनाते हैं।
नतीजा
कॉन्फ़िगरेशन रिलीज़ अब फ्रंटएंड डिप्लॉय पर निर्भर नहीं हैं, इसलिए बहु-बाज़ार अपडेट हफ़्तों से घंटों में आ गए, और क्षेत्रीय कोड का दोहराव बढ़ना बंद हो गया।