You push a fix at four on a Friday. By Saturday morning, alerts are ringing. You trace the incident to a pull request me

तुम्ही शुक्रवारी चार वाजता एक फिक्स पुश करता. शनिवारी सकाळी अलर्ट्स वाजायला लागतात. तुम्ही १८ तासांपूर्वी मर्ज केलेल्या एका पुल रिक्वेस्टचा शोध घेता. ब्रांच कंपाईल झाली, टेस्ट्स पास झाल्या, पण PR डिस्क्रिप्शन रिकामे आहे. कोणतीही वर्क आयटम लिंक नाही. अप्रूव्हल हिस्ट्रीमध्ये काहीच दिसत नाही. तुम्ही एका 'घोस्ट मर्ज'कडे पाहत आहात, आणि आता तुम्ही तुमचे वीकेंड अशा गोंधळात घालवत आहात जो main मध्ये जाण्यापूर्वीच पकडला गेला असता.

लहान टीम्स दररोज या जोखमीसह जगतात. तुमच्याकडे प्रत्येक मर्जवर लक्ष ठेवणारा रिलीज मॅनेजर नसतो. तुमच्याकडे खास पॉलिसी इंजिन्स बनवणारी प्लॅटफॉर्म टीम नसते. तुमच्याकडे Azure DevOps आहे, आणि त्याचे इन-बिल्ट ब्रांच पॉलिसीज हे एक अस्पष्ट साधन (blunt instrument) आहेत. ते एकतर दार पूर्णपणे बंद करतात किंवा पूर्णपणे उघडे ठेवतात. दोन रिव्ह्यूअर्सची अट घातली तर तुम्ही तातडीचे हॉटफिक्स रोखता. नियम शिथिल केले तर रिकामी वर्णने (descriptions) आणि विना-तिकीट बदल थेट प्रोडक्शनमध्ये जातात. मध्ये कोणताही सुवर्णमध्य असणे दुर्मिळ आहे.

हीच दरी भरून काढण्यासाठी आम्ही Gatekeeper बनवले आहे. हे Azure DevOps साठी खास डिझाइन केलेले AI-powered PR रिव्ह्यू डेस्क आहे, पण आधुनिक डेव्हलपर टूल्सबद्दल तुम्ही जे काही गृहीत धरले आहे ते सर्व विसरून जा. यात कोणताही Docker कंटेनर नाही, कोणताही सबस्क्रिप्शन प्लॅन नाही आणि कोणताही क्लाउड डिप्लॉयमेंट पाईपलाईन नाही. Gatekeeper ही एक सिंगल HTML फाईल आहे. तुम्ही ती तुमच्या ब्राउझरमध्ये उघडता, चार व्हॅल्यूज टाकता आणि एक बटण दाबता. त्यानंतर हे टूल तीन साधे प्रश्न विचारते: ही PR एखाद्या तिकीटशी लिंक आहे का? एखाद्या माणसाने खरोखर त्याची रिव्ह्यू केली आहे का? आणि कोडची क्वालिटी चांगली आहे का?

सर्व काही एकाच सेल्फ-कंटेन्ड फाईलमध्ये पॅकेज करण्याचा निर्णय हा केवळ दिखावा नव्हता. तो वास्तविक ऑपरेशनल डोकेदुखी सोडवतो. पहिले म्हणजे, होस्ट करण्यासाठी किंवा पैसे देण्यासाठी कोणतेही इन्फ्रास्ट्रक्चर नाही. तुम्हाला App Service प्रोव्हिजन करण्याची किंवा एग्रेस (egress) खर्चाची काळजी करण्याची गरज नाही. दुसरे म्हणजे, तुमचे क्रेडेंशियल्स कधीही तुमच्या मशीनच्या बाहेर जात नाहीत. तुमचा Azure DevOps पर्सनल ॲक्सेस टोकन फक्त ब्राउझर मेमरीमध्ये राहतो आणि तुम्ही पेज रिफ्रेश करताच नाहीसा होतो. लीक होण्यासाठी कोणताही सिक्रेट्सचा डेटाबेस नाही आणि विश्वास ठेवण्यासाठी कोणताही OAuth सर्व्हर नाही. तिसरे म्हणजे, याचा अवलंब करणे अत्यंत सोपे आहे. तुम्हाला कोणालाही विकी (wiki) द्वारे ऑनबोर्ड करण्याची गरज नाही. तुम्ही ही फाईल ईमेलला जोडू शकता किंवा Slack थ्रेडमध्ये टाकू शकता. प्राप्तकर्ता ती उघडतो आणि लगेच रिव्ह्यू करण्यास सुरुवात करतो.

द फॅक्ट लेअर: डेटरमिनिझम प्रथम

Gatekeeper त्याच्या रिव्ह्यूला दोन वेगळ्या लेयर्समध्ये विभागते, आणि हे विभाजन त्याच्या विश्वासार्हतेचा कणा आहे.

पहिला लेअर म्हणजे थेट Azure DevOps REST API शी संवाद साधणारा शुद्ध JavaScript आहे. तो अशा तथ्यांची (facts) तपासणी करतो जे बदलत नाहीत. एक पुल रिक्वेस्ट वर्क आयटमशी लिंक आहे किंवा नाही, हे स्पष्ट असते. एखाद्या रिव्ह्यूअरने अप्रूव्हल व्होट दिला आहे किंवा नाही, हे स्पष्ट असते. डिस्क्रिप्शन रिकामे आहे किंवा त्यात प्रत्यक्ष वाक्ये आहेत, हे स्पष्ट असते. ॲक्टिव्ह चर्चा (discussions) सोडवल्या गेल्या आहेत की अजूनही प्रलंबित आहेत, हे देखील स्पष्ट असते.

विशेषतः, फॅक्ट लेअर चार गोष्टी शोधतो:

• Ticket mapping: ही PR किमान एका वर्क आयटमशी लिंक आहे का?
• Reviewer sign-off: कोणीही अप्रूव्हलसाठी मतदान केले आहे का, की संख्या अजूनही शून्य आहे?
• Description quality: डिस्क्रिप्शन रिकामे आहे की फक्त एक साधा प्लेसहोल्डर आहे?
• Open discussions: प्रतिसादाची वाट पाहणारे काही न सुटलेले कमेंट थ्रेड्स आहेत का?

ही तपासणी पेजवर व्हिज्युअल स्टॅम्प्स तयार करते. एक मोठा लाल NOT MAPPED स्टॅम्प दुर्लक्षित करणे कठीण आहे. टेबल सेलमध्ये लपवलेले एक लहान हिरवे टिक मार्क सहज सुटू शकते. आम्हाला लवकरच समजले की प्रक्रियांमधील त्रुटी स्पष्टपणे दिसल्या पाहिजेत. जेव्हा एखादा डेव्हलपर मर्ज करण्यासाठी घाई करत असतो, तेव्हा सूक्ष्मता (subtlety) काम करत नाही. अस्पष्टता पूर्णपणे काढून टाकण्यासाठी फॅक्ट लेअर अस्तित्वात आहे.

कारण हा लेअर डेटरमिनिस्टिक API रिस्पॉन्सवर अवलंबून आहे, त्याची अचूकता पूर्णपणे खात्रीशीर आहे. जर स्टॅम्प NO APPROVAL म्हणत असेल, तर तुम्ही खात्री बाळगू शकता की कोणीही अप्रूव्ह बटण क्लिक केले नाही. जर तो UNRESOLVED THREADS म्हणत असेल, तर संभाषण अजूनही सुरू आहे. हा लेअर...