127-कमिट वाली रिलीज़ असल में क्या होती है

इस ब्लॉग पोस्ट का एक ऐसा रूप भी है जो बस GeekBye v1.7.0 की हर चीज़ गिना देता है — एक नया होम स्क्रीन, एक कैलिब्रेशन फ़्लो, एक समेटी जा सकने वाली साइडबार, नई सेटिंग्स, और यूँ ही आगे। वह सटीक होता और आपको कुछ न सिखाता। क्योंकि एक 127-कमिट वाली रिलीज़ की ईमानदार कहानी वह सूची नहीं है। वह उसका आकार है।

यह रहा आकार। एक सौ सत्ताईस कमिट सुनने में एक सौ सत्ताईस छोटी-छोटी चीज़ों जैसे लगते हैं। लगभग कभी नहीं होते। v1.7.0 दो बड़े फ़ीचर थे, जो करीब ग्यारह दिनों में लंबे समय तक चलने वाली branch पर समानांतर बने, और अंत में आपस में गुँथ गए। एक बड़ी रिलीज़ को समझने का मतलब है उन दो लड़ियों को समझना — और वह एक जगह जहाँ हमने कुछ गलत स्थान पर बनाया और उड़ान के बीचोबीच उसे वापस उखाड़ना पड़ा।

लड़ी एक: कैलिब्रेशन

पहली लड़ी थी कैलिब्रेशन — आपकी संवाद-कुशलता का एक AI आवाज़-आकलन। आप एक AI "करियर कोच" के साथ एक लाइव कॉल शुरू करते हैं, चरणों के एक संरचित समुच्चय (वार्मअप, व्यवहारगत, तकनीकी संवाद, दबाव-प्रतिक्रिया, लक्ष्य-निर्धारण) से गुज़रते हैं, और अंत में आपको छह आयामों पर स्कोर मिलता है: आत्मविश्वास, स्पष्टता, विशिष्टता, संलग्नता, संयम, प्रासंगिकता। भीतर, यह ठोस भाषण मापदंड भी नापता है — आपकी बोलने की गति, भराव-शब्दों की बारंबारता, आपके ठहराव रणनीतिक लगते हैं या हिचकिचाहट भरे।

नतीजा कोई ग्रेड नहीं है, यह एक शुरुआती बिंदु है। कैलिब्रेशन आपकी ताकतें, आपके विकास-क्षेत्र, और — सबसे अहम — अभ्यास शुरू करने के लिए एक अनुशंसित कठिनाई तैयार करता है। यह आँकता है कि उत्पाद आपसे कहाँ मिले। हर कौशल एक फैलाई जा सकने वाली फ़ीडबैक कार्ड के रूप में वापस आता है जिसमें एक सारांश, एक ठोस सुझाव, और उदाहरण के तौर पर आपकी अपनी कॉल से उद्धृत एक असली पंक्ति होती है। यही वह फ़ीचर है जिसके ऊपर बाकी का अभ्यास-अनुभव बना है।

लड़ी दो: एक बिलकुल नई विंडो

दूसरी लड़ी थी एक प्रीमियम रीडिज़ाइन — और इसे रीडिज़ाइन कहना इसे कमतर आँकना है। यह मौजूदा स्क्रीनों की कोई रीस्किन नहीं थी; यह असल में एक दूसरी एप्लिकेशन विंडो थी, जो छह स्पष्ट चरणों में बनी: एक समेटी जा सकने वाली Notion-शैली की साइडबार, एक हेडर ड्रॉपडाउन जिसने पुरानी सेशन सूची की जगह ली, इतिहास और ब्रेडक्रम्ब के साथ ब्राउज़र-शैली का नेविगेशन, और Home, Profiles, Meetings, तथा Settings के प्रीमियम रीबिल्ड।

दो बड़े फ़ीचर। 127 कमिट असल में यही थे। और उन्हें भेजने का सबसे कठिन हिस्सा उनमें से किसी को लिखना नहीं था — वह था गूँथना। दोनों branch एक-दूसरे पर निर्भर थीं; एक को दूसरी में merge किया गया, और कैलिब्रेशन branch को main branch से चार अलग-अलग बार खींचना पड़ा बस इसलिए कि जब नीचे रीडिज़ाइन खिसक रहा था तब वह तालमेल से बाहर न हो जाए। कमिट की गिनती एक बड़ी रिलीज़ की लागत नहीं है। लंबे समय तक चलने वाली branch और इंटीग्रेशन का क्रम हैं।

पढ़ने लायक हिस्सा: हमने कैलिब्रेशन गलत जगह बनाया

यह रही गलती, और यह एक अच्छी गलती है क्योंकि यह इतनी आम है।

GeekBye का एक पक्का आर्किटेक्चरल नियम है: सभी AI ऑपरेशन backend पर रहते हैं। client एक पतला खोल है जो एक सर्वर से बात करता है। यह सब जानते थे।

और फिर भी कैलिब्रेशन पहले client के लोकल डेटाबेस में बनाया गया। एक समर्पित टेबल, एक डेटाबेस माइग्रेशन, एक 254-लाइन का रिपॉज़िटरी, IPC हैंडलर, और आकलन प्रश्नों का एक 515-लाइन का भंडार — सब कुछ उपयोगकर्ता की मशीन पर रहता हुआ। यह काम करता था। यह चुपचाप उस अनुबंध का उल्लंघन भी करता था जिस पर पूरा ऐप बना है।

तीन दिन बाद, एक कमिट ने आठ फ़ाइलों में 680 लाइनें मिटाकर सब कुछ backend पर ले जाया, जहाँ कैलिब्रेशन डेटा एक उचित सर्वर-साइड मॉडल बन गया, और प्रश्न-तर्क तथा स्कोरिंग एक सर्वर की चिंता बन गए। एक और कमिट ने 515-लाइन का client प्रश्न-भंडार पूरी तरह मिटा दिया। यह diff लगभग हास्यास्पद है: एक इंसर्शन, छह सौ अस्सी डिलीशन।

किसी ने 680 लाइन फेंकने लायक कोड लिखने का इरादा नहीं किया था। यह उसी तरह हुआ जैसे हमेशा होता है: client वाला शॉर्टकट ठीक वहीं मौजूद है, लोकल में प्रोटोटाइप बनाना तेज़ है, और "हम इसे बाद में backend पर ले जाएँगे" हानिरहित महसूस होता है। पर जब आपका आर्किटेक्चर पहले ही बता देता है कि source of truth कहाँ रहती है, तो उसे कहीं और बनाना कोई शॉर्टकट नहीं है — यह वह दोबारा-काम है जो आपने अपने लिए पहले से शेड्यूल कर रखा है। जो सबक टिका: उसे वहीं रखो जहाँ अनुबंध कहता है, पहली ही बार में, तब भी जब लोकल वर्शन खड़ा करना ज़्यादा तेज़ हो।

वह बग जो सिर्फ़ इंटीग्रेशन ही ढूँढ सकता था

एक और रसीद, क्योंकि यह बड़ी रिलीज़ों का हस्ताक्षर-जैसा विफलता-रूप है। जब कैलिब्रेशन और नया नेविगेशन आपस में जुड़कर सचमुच चलने लगे, तो ऐप बिना किसी साफ़ कारण के एक रेट लिमिट — HTTP 429 — छेड़ने लगा।

वजह शुद्ध इंटीग्रेशन थी। कैलिब्रेशन स्टेटस कंपोनेंट स्तर पर fetch हो रहा था, इसलिए हर नेविगेशन उसे दोबारा fetch करता — और React का strict mode, जो बग सामने लाने के लिए जान-बूझकर डेवलपमेंट में effects को दो बार चलाता है, उसे फिर से दोगुना कर देता। नतीजा था हर स्क्रीन बदलाव पर चार से आठ एक-जैसे कैलिब्रेशन अनुरोध, जो सर्वर के रेट लिमिटर को छेड़ने के लिए काफ़ी थे। हल ने fetching को mount पर बस कुछ कॉलों में समेट दिया।

आप यह बग कैलिब्रेशन को अकेले, या नेविगेशन को अकेले, परखकर नहीं ढूँढ सकते थे। यह सिर्फ़ उस जोड़ पर मौजूद है — जहाँ दो स्वतंत्र रूप से सही फ़ीचर मिलते हैं। यही वह कर है जो एक बड़ी रिलीज़ वसूलती है: आख़िरी मील फ़ीचर बनाना नहीं है, यह उन सबको खोजना है जो तभी टूटते हैं जब वे आख़िरकार एक ही कमरे में हों।

एक बड़ी रिलीज़ ने सिखाई तीन बातें

1. एक 127-कमिट वाली रिलीज़ दो या तीन बड़े विषय होते हैं, सौ छोटे नहीं। लड़ियाँ ढूँढो। काम — और जोखिम — इसमें बसता है कि वे कैसे आपस में गुँथते हैं, गिनती में नहीं।
2. source of truth वहीं रखो जहाँ अनुबंध कहता है कि वह रहती है, पहली ही बार में। हमने कैलिब्रेशन को client से backend पर हटाते हुए 680 लाइनें मिटाईं। लोकल शॉर्टकट वह दोबारा-काम है जो आपने पहले से शेड्यूल कर रखा है; आर्किटेक्चर पहले ही जवाब बता चुका था।
3. इंटीग्रेशन उन विफलताओं को सामने लाता है जो अलगाव नहीं ला सकता। 429 का तूफ़ान दो सही फ़ीचरों के बीच के जोड़ पर बसता था और तभी दिखा जब वे साथ चले। सिर्फ़ प्रति-फ़ीचर परीक्षण नहीं, बल्कि एक इंटीग्रेशन दौर के लिए बजट रखो।

यह एक ऐसी कहानी का v1-कालीन चचेरा भाई है जिसे हम कहीं बड़े पैमाने पर फिर से कहेंगे — देखें एक वर्शन 2 असल में क्या माँगता है: ईमानदार अवस्थाओं के 206 कमिट (v2.0.0), जहाँ वही "एक बड़ा आँकड़ा असल में कुछ बड़े विचार होते हैं" वाला सच पूरे v2 पुनर्लेखन में खुलता है। v1 कहानी के पिछले अध्याय के लिए, बिना झिलमिलाहट के लाइव रिपोर्ट स्ट्रीम करने का तरीका (v1.6.13); और पूरे चाप के लिए, सॉफ़्टवेयर को परिपूर्णता तक पहुँचाकर भेजने की शारीर-रचना।