AI एजेंट और मंज़ूरी के साथ GitHub रिलीज़ ऑटोमेशन

रिलीज़ ऑटोमेशन का काम दफ्तरनुमा दोहराव वाले काम हटाना है, किसी कोडिंग एजेंट को यह अधिकार देना नहीं कि उसे जब सॉफ्टवेयर तैयार लगे, वह उसे बाँट दे। एजेंट बदलाव इकट्ठा कर सकता है, वर्ज़न निकाल सकता है, रिलीज़ कैंडिडेट बना सकता है, नोट्स का ड्राफ्ट तैयार कर सकता है और आर्टिफैक्ट जोड़ सकता है। पब्लिशिंग और रोलबैक से पहले किसी व्यक्ति को ठोस रिलीज़ अनुरोध देखना और उसी कार्रवाई को मंज़ूरी देना चाहिए।

यह सीमा तब तक ज़रूरत से ज़्यादा सावधान लग सकती है, जब तक आपको गलत बाइनरी, बदले हुए टैग या ऐसे नोट्स वाली रिलीज़ ठीक न करनी पड़े जिनमें ऐसे सुधार का वादा हो जो कभी भेजा ही नहीं गया। API कॉल आसान है। उसके परिणामों को पलटना आम तौर पर आसान नहीं होता।

एजेंट को रिलीज़ वर्कबेंच दें, रिपॉज़िटरी का स्वामित्व नहीं

रिलीज़ एजेंट के पास कार्रवाइयों का छोटा और स्पष्ट सेट होना चाहिए, जो उसके काम से सीधे मेल खाए। व्यापक रिपॉज़िटरी लिखने की अनुमति सुविधाजनक लगती है, क्योंकि इससे इंटरफ़ेस बनाने की ज़रूरत नहीं पड़ती। लेकिन इसी से गलत निर्देश रिलीज़ कार्य को टैग हटाने, ब्रांच बदलने, वर्कफ़्लो संपादित करने या सार्वजनिक घोषणा में बदल सकता है।

GitHub रिलीज़ ऑटोमेशन में मैं तैयारी और वितरण को अलग रखता हूँ। एजेंट रिपॉज़िटरी का मेटाडेटा पढ़ सकता है, मंज़ूर की गई रेंज में कमिट देख सकता है, बिल्ड चला सकता है, आर्टिफैक्ट हैश निकाल सकता है, ड्राफ्ट रिलीज़ बना या अपडेट कर सकता है और उसमें आर्टिफैक्ट अपलोड कर सकता है। वह रिलीज़ पब्लिश, रिलीज़ हटाने, टैग बदलने, रिपॉज़िटरी सेटिंग संपादित करने, टोकन बनाने या किसी भी मनमाने GitHub endpoint को कॉल नहीं कर सकता।

अनुमत कार्रवाइयों को निश्चित इनपुट वाले क्रियापदों के रूप में लिखें। यह एजेंट से «सावधान रहने» को कहने से कहीं उपयोगी है।

• inspect_release_range(base_tag, head_sha) कमिट और पुल रिक्वेस्ट लौटाता है
• build_candidate(head_sha) आर्टिफैक्ट और SHA-256 डाइजेस्ट लौटाता है
• create_draft(version, target_sha, notes) ड्राफ्ट पहचानकर्ता लौटाता है
• upload_asset(draft_id, filename, digest) एक सत्यापित फ़ाइल अपलोड करता है
• request_publish(draft_id) मंज़ूरी अनुरोध बनाता है

आखिरी क्रियापद महत्वपूर्ण है। अगर कोई जवाब न दे, तो request_publish को चुपचाप पब्लिश नहीं करना चाहिए। उसे लंबित स्थिति लौटानी चाहिए, जिसे कॉल करने वाला दिखा और जाँच सके। जो रिलीज़ वर्कफ़्लो समय समाप्त होने को सहमति मानता है, वह अपने ही नियंत्रण को खत्म कर चुका है।

github_api(method, path, body) जैसा कोई बच निकलने का रास्ता न रखें। टीमें इसे उस असामान्य कार्रवाई के लिए जोड़ती हैं जो शुरुआती डिज़ाइन में फिट नहीं हुई। एजेंट अंततः इसका इस्तेमाल करेगा, क्योंकि भाषा मॉडल इंटरफ़ेस में सबसे छोटा रास्ता पसंद करते हैं। हर अनियंत्रित अनुरोध विधि आपके सीमित अधिकार को फिर से सामान्य रिपॉज़िटरी टोकन में बदल देती है।

यही नियम शेल एक्सेस पर भी लागू होता है। मनमाने आर्ग्युमेंट के साथ gh उपलब्ध कराकर उसे रिलीज़ इंटरफ़ेस न कहें। जिन कार्रवाइयों को स्वीकार करना है, उनके लिए रैपर बनाएँ, आर्ग्युमेंट की जाँच करें और बाकी सब अस्वीकार करें। अगले महीने नई कार्रवाई चाहिए तो उसे सोच-समझकर जोड़ें, टेस्ट करें और तय करें कि पुष्टि कहाँ चाहिए।

ड्राफ्ट रिलीज़ समीक्षा की वस्तु है, प्रकाशित रिलीज़ नहीं

GitHub ड्राफ्ट रिलीज़ आपको सार्वजनिक रिकॉर्ड तैयार करने देती है, बिना उसे सार्वजनिक किए। इससे समीक्षक के पास जाँचने के लिए कुछ ठोस होता है: वर्ज़न, लक्ष्य कमिट, बनाए गए नोट्स, संलग्न फ़ाइलें, चेकसम और प्री-रिलीज़ स्थिति। «v2.4.0 पब्लिश करने के लिए तैयार है» कहना पर्याप्त प्रमाण नहीं है।

GitHub के REST दस्तावेज़ में draft: true के साथ रिलीज़ बनाने और ड्राफ्ट स्थिति बदलकर उसे पब्लिश करने के बीच अंतर बताया गया है। GitHub यह भी बताता है कि make_latest से यह तय होता है कि GitHub किस रिलीज़ को नवीनतम दिखाएगा। ये फ़ील्ड सामान्य मेटाडेटा लग सकते हैं, लेकिन इनका असर उपयोगकर्ताओं और टूलिंग पर पड़ता है। इन्हें पब्लिशिंग विकल्प मानें, ऐसे डिफ़ॉल्ट नहीं जिन्हें एजेंट खुद तय करे।

एक अच्छे अनुरोध में अपरिवर्तनीय पहचानकर्ता होते हैं। वर्ज़न स्ट्रिंग लोगों के लिए उपयोगी है, लेकिन कमिट SHA उस स्रोत की पहचान करता है जिसकी आपने वास्तव में समीक्षा की। आर्टिफैक्ट डाइजेस्ट उस फ़ाइल की पहचान करता है जिसे आपने वास्तव में बनाया। अगर अनुरोध केवल «v2.4.0 पब्लिश करें» कहता है, तो समीक्षक को रिलीज़ फिर से बनाकर समझनी पड़ेगी और एजेंट इंतज़ार करता रहेगा।

इस तरह का संरचित मंज़ूरी रिकॉर्ड इस्तेमाल करें:

{
  "operation": "publish_release",
  "repository": "acme/widgets",
  "draft_id": "123456",
  "version": "v2.4.0",
  "target_sha": "8b0c5f7c2d6c4e1a9f1a3b0e5e92d7a4c6f80c11",
  "prerelease": false,
  "make_latest": "true",
  "assets": [
    {"name": "widgets-v2.4.0.tar.gz", "sha256": "b3e1..."},
    {"name": "widgets-v2.4.0.tar.gz.sha256", "sha256": "f18a..."}
  ],
  "notes_digest": "c921..."
}

मंज़ूरी देने वाले को ड्राफ्ट खोलकर इस रिकॉर्ड की रिपॉज़िटरी स्थिति से तुलना करनी चाहिए। नोट्स के डाइजेस्ट की ज़रूरत ज़्यादा लग सकती है, जब तक कोई समीक्षा के बाद ड्राफ्ट संपादित न कर दे। हर कॉमा को अपरिवर्तनीय बनाने की ज़रूरत नहीं, लेकिन यह पता होना चाहिए कि आर्टिफैक्ट सूची, लक्ष्य या रिलीज़ वर्गीकरण बदला है या नहीं।

ड्राफ्ट अपने-आप सुरक्षित नहीं होती। वह रिपॉज़िटरी एक्सेस वाले उपयोगकर्ताओं को दिखाई दे सकती है और आंतरिक टूलिंग शुरू कर सकती है। ड्राफ्ट बनाना कम जोखिम वाली सूची में तभी रखें, जब आपका वातावरण उसे समीक्षा सामग्री की तरह संभालता हो। अगर ड्राफ्ट के आर्टिफैक्ट पैकेज रजिस्ट्री या आर्टिफैक्ट मिरर में चले जाते हैं, तो अपलोड से पहले भी मंज़ूरी लें।

वर्ज़न को कमिट से और आर्टिफैक्ट को वर्ज़न से बाँधें

सबसे आम रिलीज़ विफलता कोई दुर्भावनापूर्ण एजेंट नहीं है। समस्या यह होती है कि रिलीज़ का वर्ज़न, टैग, स्रोत कमिट और बाइनरी चलते हुए रिपॉज़िटरी से अलग-अलग समय पर आते हैं।

एक साफ़ प्रक्रिया पहले अपरिवर्तनीय कमिट SHA चुनती है। बिल्ड ब्रांच नाम से नहीं, उसी SHA से चलता है। बिल्ड पूरा होने के बाद एजेंट डाइजेस्ट दर्ज करता है। इसके बाद ही वह ऐसा टैग और ड्राफ्ट बनाता है जो उसी SHA की ओर इशारा करते हैं। अगर रिलीज़ प्रक्रिया में साइन किया हुआ टैग चाहिए, तो साइनिंग पहचान एजेंट प्रक्रिया से बाहर काम करे, ठीक वैसे ही जैसे पब्लिशिंग क्रेडेंशियल।

एजेंट को सार्वजनिक रिलीज़ के लक्ष्य के रूप में main जैसे बदल सकने वाले रेफरेंस का इस्तेमाल न करने दें। बिल्ड एक रिविज़न पर शुरू हो सकता है, जबकि एजेंट रिलीज़ बनाने से पहले कोई दूसरा मर्ज ब्रांच को आगे बढ़ा दे। अगर आपका कोड उस समय main को हल करने को कहता है, तो GitHub खुशी-खुशी रिलीज़ को बाद के लक्ष्य से जोड़ देगा। इससे नोट्स एक रिविज़न का और आर्टिफैक्ट दूसरे का हो सकता है।

मंज़ूरी प्रॉम्प्ट से पहले संबंध की जाँच करें। एक सरल स्थानीय सत्यापन जल्दी विफल हो सकता है:

git fetch --tags origin
git rev-parse "v2.4.0^{}"
git rev-parse HEAD
shasum -a 256 dist/widgets-v2.4.0.tar.gz

टैग बनने के बाद पहले दो ऑब्जेक्ट आईडी समान होनी चाहिए, और अगर आपने उसी चेकआउट में बिल्ड किया है तो HEAD वही समीक्षित SHA होना चाहिए। चेकसम कमांड इस आकार की पंक्ति बनाती है:

b3e1f2...  dist/widgets-v2.4.0.tar.gz

ठीक वही डाइजेस्ट मंज़ूरी रिकॉर्ड में डालें। समीक्षक से केवल फ़ाइल नाम पर भरोसा करने को न कहें। widgets-v2.4.0.tar.gz नाम वाली फ़ाइल में डीबग बिल्ड, पुराना बिल्ड या किसी दूसरे आर्किटेक्चर की बाइनरी हो सकती है।

GitHub Actions का दस्तावेज़ चेतावनी देता है कि pull_request_target बेस रिपॉज़िटरी के संदर्भ में चलता है और लापरवाही से इस्तेमाल करने पर अविश्वसनीय पुल रिक्वेस्ट कोड के सामने लिखने की अनुमतियाँ या सीक्रेट खोल सकता है। यही सीख रिलीज़ एजेंट पर भी लागू होती है: ऐसे जॉब में अविश्वसनीय कोड से वितरण योग्य आर्टिफैक्ट न बनाएँ जिसमें पब्लिश करने की क्षमता हो। अविश्वसनीय सत्यापन को उस नियंत्रित बिल्ड से अलग रखें जिसे रिलीज़ अधिकार मिलते हैं।

वर्ज़न निकालने के लिए भी तय नियम चाहिए। एजेंट conventional commits या मर्ज किए गए लेबल से वर्ज़न प्रस्तावित कर सकता है, लेकिन प्रस्ताव प्रमाण नहीं है। मेंटेनर को तय करना चाहिए कि breaking changes, वापस किए गए बदलाव और रिलीज़ ब्रांच वर्ज़निंग को कैसे प्रभावित करेंगे। जब रिपॉज़िटरी में कमिट अनुशासन एक जैसा न हो, तो ऑटोमेटेड semantic versioning चुपचाप गलत हो सकती है।

बनाए गए रिलीज़ नोट्स को मानव संपादक चाहिए

एजेंट मर्ज किए गए पुल रिक्वेस्ट को विश्वसनीय शुरुआती ड्राफ्ट में बदल सकता है। लेकिन उसे यह पता नहीं हो सकता कि किसी माइग्रेशन के साथ चेतावनी चाहिए, कोई योगदानकर्ता श्रेय चाहता है या ऐसा व्यवहार बदलाव किसी उपयोग-स्थिति को तोड़ता है जिसका उल्लेख कमिट शीर्षक में कभी नहीं हुआ।

उससे ऐसे सेक्शन में नोट्स बनाने को कहें जो अनिश्चितता स्पष्ट करें। पहले उपयोगकर्ता के लिए बदलाव, फिर सुधार और उसके बाद आंतरिक काम रखें। पुल रिक्वेस्ट संदर्भ और इस्तेमाल की गई कमिट रेंज शामिल करें। कोड निरीक्षण से आए दावों को मेंटेनर के विवरण से आए दावों से अलग चिह्नित करें। इससे सहज लगने वाला पैराग्राफ किसी अनुमान को छिपा नहीं पाएगा।

मैं लोकप्रिय निर्देश «git log से शानदार रिलीज़ नोट्स लिखो» को स्वीकार नहीं करता। यह लोकप्रिय इसलिए है कि तुरंत दस्तावेज़ दे देता है। यह गलत है, क्योंकि कमिट संदेश लागू करने का इरादा बताते हैं, ज़रूरी नहीं कि भेजे गए व्यवहार को। fix auth नाम का कमिट टेस्ट फ़िक्सचर ठीक कर सकता है, त्रुटि संदेश बदल सकता है या गंभीर समस्या बंद कर सकता है। रिलीज़ नोट में वास्तविक उपयोगकर्ता प्रभाव चाहिए।

पब्लिश करने से पहले समीक्षक से कुछ सीधे सवालों के जवाब लें:

• क्या लक्ष्य कमिट में यहाँ बताए गए सभी बदलाव हैं?
• क्या हटाई या वापस की गई कोई पुल रिक्वेस्ट रेंज में रह गई है?
• क्या उपयोगकर्ताओं को कॉन्फ़िगरेशन, डेटा, अनुमतियों या क्लाइंट में बदलाव करना होगा?
• क्या सुरक्षा संबंधी भाषा की समीक्षा उन लोगों को करनी चाहिए जिन्होंने इसकी जाँच की थी?
• क्या यह प्री-रिलीज़ है, और क्या GitHub को इसे नवीनतम दिखाना चाहिए?

एजेंट को सुरक्षा सलाह देकर उसे सार्वजनिक रिलीज़ के लिए दोबारा लिखने को न कहें। खुलासा कब करना है, प्रभावित वर्ज़न, समाधान और श्रेय का निर्णय समीक्षक को करना चाहिए। एजेंट मंज़ूर भाषा को फ़ॉर्मैट कर सकता है, लेकिन यह तय नहीं करना चाहिए कि सार्वजनिक क्या होगा।

समीक्षा के समय रिलीज़ नोट्स और रिलीज़ आर्टिफैक्ट को साथ रखें। जब समीक्षक पढ़े «ARM सपोर्ट जोड़ा गया है», तो उसे ड्राफ्ट में ARM आर्टिफैक्ट और मंज़ूरी अनुरोध में उसका चेकसम भी दिखना चाहिए। इससे ऐसी शर्मनाक गलतियाँ पकड़ में आती हैं जिन्हें अलग-अलग दस्तावेज़ और बिल्ड समीक्षा नहीं पकड़ पाती।

पुष्टि अपरिवर्तनीय सीमा पर होनी चाहिए

पब्लिश होने के बाद दिखाई देने वाला पुष्टि संवाद केवल पछतावे का रिकॉर्ड बनाता है। प्रॉम्प्ट उसी कार्रवाई से ठीक पहले रखें जो वितरण की स्थिति बदले और जिसे अधिकृत किया जा रहा है उसका सटीक अनुरोध दिखाएँ।

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

इन कार्रवाइयों के लिए अलग पुष्टि लें:

• ड्राफ्ट रिलीज़ पब्लिश करना
• रिलीज़ हटाना या अनपब्लिश करना
• रिलीज़ टैग हटाना
• मौजूदा रिलीज़ आर्टिफैक्ट बदलना
• रिलीज़ को प्री-रिलीज़ से स्थिर करना या उसे नवीनतम चिह्नित करना

यह सूची जानबूझकर छोटी है। हर रीड और हर आर्टिफैक्ट हैश के लिए अनुमति माँगने से लोग बिना देखे मंज़ूरी देना सीख जाते हैं। सार्वजनिक या विनाशकारी सीमा पर निर्णय लेना ध्यान वहीं लगाए रखता है जहाँ उसका असर हो सकता है।

पुष्टि को अनुरोध डाइजेस्ट से बाँधें। अगर एजेंट ड्राफ्ट बदलता है, आर्टिफैक्ट जोड़ता है या मंज़ूरी के बाद make_latest बदलता है, तो मंज़ूरी अमान्य करें और फिर से पूछें। केवल इसलिए पिछली क्लिक को दोबारा इस्तेमाल न करें कि वर्ज़न स्ट्रिंग अभी भी वही है।

Sallyport की प्रति-सेशन अनुमति किसी कार्रवाई से पहले नई एजेंट प्रक्रिया की पहचान कर सकती है और उसकी प्रति-कॉल नियंत्रण व्यवस्था चुने हुए क्रेडेंशियल के इस्तेमाल के लिए अलग मंज़ूरी माँग सकती है। यह रिलीज़ कार्य से अच्छी तरह मेल खाता है: समीक्षा किए गए एजेंट रन को ड्राफ्ट तैयार करने दें, फिर पब्लिशिंग क्रेडेंशियल इस्तेमाल करते समय प्रति-कॉल निर्णय लें।

मंज़ूरी को प्रमाणीकरण न समझें। कोड-साइनिंग पहचान या CI workload identity बताती है कि अनुरोध किस प्रक्रिया ने किया। पुष्टि बताती है कि किसी मानव ने इस खास बाहरी कार्रवाई को स्वीकार किया। रिलीज़ गलत होने पर दोनों रिकॉर्ड चाहिए।

क्रेडेंशियल को एजेंट के प्रॉम्प्ट और एनवायरनमेंट से बाहर रखें

जिस एजेंट के पास सीधे GitHub टोकन हो, वह आपके सावधानी से बनाए गए मंज़ूरी इंटरफ़ेस को curl कमांड, बदली हुई वर्कफ़्लो फ़ाइल या ऐसे टूल कॉल से पार कर सकता है जिसे आप सीमित करना भूल गए। प्रॉम्प्ट निर्देश इस अंतर को बंद नहीं कर सकते।

क्रेडेंशियल को ऐसे घटक में रखें जो केवल अनुमत कार्रवाई चलाए। एजेंट संरचित अनुरोध भेजता है। घटक रिपॉज़िटरी, क्रियापद, लक्ष्य रेफरेंस और आर्टिफैक्ट सीमाओं की जाँच करता है, ज़रूरी मंज़ूरी लेता है, बाहरी अनुरोध में क्रेडेंशियल जोड़ता है और परिणाम लौटाता है। एजेंट को सीक्रेट कभी नहीं मिलता, छिपे हुए प्लेसहोल्डर के रूप में भी नहीं।

Sallyport API और SSH सीक्रेट को अपने एन्क्रिप्टेड वॉल्ट में रखता है और HTTP या SSH कार्रवाई खुद चलाता है, इसलिए MCP-सक्षम एजेंट को क्रेडेंशियल रखने की ज़रूरत नहीं होती। उसका वॉल्ट गेट लॉक रहने पर कार्रवाई रोक देता है। बिना निगरानी वाली मशीन की स्थिति में यही व्यवहार चाहिए, न कि शेल एनवायरनमेंट में पड़ा हुआ टोकन।

रिलीज़ के लिए अलग क्रेडेंशियल रखें। उसका दायरा केवल उन रिपॉज़िटरी तक सीमित करें जहाँ उसे काम करना है और संगठन का प्रशासन, वेबहुक प्रबंधन, Actions सेटिंग संपादन या असंबंधित रिपॉज़िटरी में लिखने की अनुमति हटा दें। GitHub Apps अक्सर मानव के निजी टोकन से बेहतर बैठते हैं, क्योंकि उनके इंस्टॉलेशन और अनुमतियों का उद्देश्य सीमित होता है। सही चुनाव आपकी रिपॉज़िटरी व्यवस्था पर निर्भर है, लेकिन साझा मेंटेनर टोकन खराब रिलीज़ पहचान है।

टोकन को एजेंट निर्देश, .env फ़ाइल या CI आर्टिफैक्ट में न चिपकाएँ। रिडैक्शन समस्या हल नहीं करता। जब कोई प्रक्रिया सीक्रेट पढ़ सकती है, तो वह उसे आउटपुट फ़ील्ड, रिलीज़ बॉडी, फ़ाइल नाम या किसी दूसरी सेवा को किए गए अनुरोध में अक्सर छिपाकर भेज सकती है। रोकथाम की शुरुआत सीक्रेट उस प्रक्रिया तक कभी न पहुँचाने से होती है।

रोलबैक सुधारात्मक रिलीज़ का निर्णय है, डिलीट बटन नहीं

GitHub रिलीज़ हटाने से पेज हट सकता है, लेकिन डाउनलोड किए गए आर्काइव, कैश्ड मेटाडेटा, क्लोन किए गए टैग, मिरर किए गए स्रोत या पहले से शुरू हुआ स्वचालित डिप्लॉयमेंट वापस नहीं आता। जो रिलीज़ एजेंट हटाने को साफ़-सुथरा undo मानता है, वह खराब घटना की जाँच और कठिन बना देगा।

रोलबैक अनुरोध की शुरुआत विफलता के वर्गीकरण से करें। अगर आर्टिफैक्ट खराब लेकिन हानिरहित है, तो स्पष्ट नोट के साथ सुधारित रिलीज़ पब्लिश करें और तय करें कि पिछली रिलीज़ को प्री-रिलीज़ बनाना है या उसे नवीनतम स्थिति से हटाना है। अगर आर्टिफैक्ट में सीक्रेट, दुर्भावनापूर्ण कोड या गंभीर कमजोरी है, तो पहले वितरण रोकें, प्रभावित क्रेडेंशियल रद्द करें, अपने चैनलों से उपयोगकर्ताओं से संपर्क करें और जाँच के लिए ज़रूरी प्रमाण सुरक्षित रखें।

रोलबैक कार्रवाइयों को पब्लिशिंग से अलग मानव मंज़ूरी मिलनी चाहिए, क्योंकि उनके परिणाम अलग होते हैं। प्रॉम्प्ट में बताएं कि क्या बदलेगा और क्या दिखाई देता रहेगा। «v2.4.0 रिलीज़ हटाएँ» कमज़ोर है। «v2.4.0 का सार्वजनिक रिलीज़ रिकॉर्ड और आर्टिफैक्ट हटाएँ; v2.4.0 टैग SHA X पर बना रहेगा; मौजूदा डाउनलोड वापस नहीं लिए जा सकते» बताता है कि मंज़ूरी देने वाला वास्तव में किस चीज़ को अधिकृत कर रहा है।

एजेंट को केवल रिलीज़ नोट्स को साफ़ दिखाने के लिए टैग हटाने न दें। दूसरे बिल्ड और उपयोगकर्ता उन टैग पर निर्भर हो सकते हैं। अगर टैग बदलना ज़रूरी हो, तो पुराना SHA घटना रिकॉर्ड में रखें और बदलाव की सूचना दें। प्रकाशित वर्ज़न टैग को खिसकाने से बाद में सत्यापन बहुत कठिन हो जाता है।

सुरक्षित डिफ़ॉल्ट सुधारात्मक वर्ज़न है। इससे साफ़ ऑडिट पथ बनता है, downstream टूलिंग को सुधारे गए आर्टिफैक्ट की पहचान करने में मदद मिलती है और यह दिखावा नहीं होता कि पहली रिलीज़ कभी हुई ही नहीं। किसी के उपयोग करने से पहले गलती से पब्लिश हुई रिलीज़ के लिए हटाने की जगह हो सकती है, लेकिन यह संचालन संबंधी निर्णय है, स्वचालित सफ़ाई कार्य नहीं।

ऑडिट ट्रेल को कार्रवाई फिर से बनानी चाहिए, उसके आसपास की कहानी नहीं

जब कोई पूछे कि वर्ज़न किसने पब्लिश किया, तो «एजेंट ने» जवाब नहीं है। आपको एजेंट प्रक्रिया, कार्रवाई मंज़ूर करने वाले व्यक्ति, उसे चलाने वाले क्रेडेंशियल प्राधिकरण, अनुरोध के मान और GitHub के उत्तर की पहचान करनी होगी।

एजेंट सेशन के लिए एक और हर रिलीज़ कार्रवाई के लिए एक अलग इवेंट दर्ज करें। सेशन रिकॉर्ड बताता है कि रन किसने शुरू किया और उसका अधिकार कब समाप्त हुआ। कार्रवाई रिकॉर्ड बताता है कि endpoint के समकक्ष कौन-सी कार्रवाई हुई और हल किए गए मान क्या थे। दोनों में सीक्रेट न रखें।

पब्लिशिंग इवेंट में कम से कम रिपॉज़िटरी, ड्राफ्ट पहचानकर्ता, रिलीज़ पहचानकर्ता, वर्ज़न, लक्ष्य SHA, एजेंट द्वारा दिया गया स्रोत रेफरेंस, आर्टिफैक्ट नाम और डाइजेस्ट, रिलीज़ फ़्लैग, नोट्स डाइजेस्ट, निर्णय का समय, मंज़ूरी देने वाली पहचान, प्रक्रिया पहचान, परिणाम कोड और प्रतिक्रिया पहचान दर्ज करें। विफलताएँ भी शामिल करें। अस्वीकृत अनुरोध इस बात का प्रमाण है कि सीमा ने काम किया।

Sallyport अपने write-blind एन्क्रिप्टेड और hash-chained ऑडिट लॉग से सेशन और गतिविधि जर्नल तैयार करता है। उसका sp audit verify कमांड वॉल्ट सीक्रेट के बिना ciphertext पर ऑफलाइन चेन की जाँच करता है। रिलीज़ प्रमाण के लिए यह उपयोगी है, क्योंकि ऑडिटर क्रेडेंशियल सामग्री पाए बिना यह जाँच सकता है कि रिकॉर्ड बदले गए हैं या नहीं।

लॉग नियंत्रणों की जगह नहीं लेते। गलत पैकेज पब्लिश करने वाले एजेंट का सही लॉग आपको साफ़ पोस्टमॉर्टम और खराब रिलीज़ देगा। लॉग तब उपयोगी है जब उसके साथ सीमित कार्रवाइयाँ, स्थिर पहचानकर्ता और ऐसा अप्रभावी न होने वाला अप्रूवल हो जो बदले हुए अनुरोध के बाद भी कायम न रहे।

तथ्य बदलने पर रिलीज़ गेट को सुरक्षित रूप से रुकना चाहिए

रिलीज़ गेट को अस्पष्टता अस्वीकार करनी चाहिए, न कि समीक्षक से उसे संभालने की अपेक्षा करनी चाहिए। अगर ड्राफ्ट का लक्ष्य समीक्षित SHA से अलग हो, आर्टिफैक्ट डाइजेस्ट बिल्ड मैनिफेस्ट से अलग हो, ड्राफ्ट मौजूद न रहे या मंज़ूरी के बाद रिलीज़ अनुरोध बदल गया हो, तो रुकें और नया अनुरोध बनाएँ।

रिलीज़ की जल्दी में यह व्यवहार ज़रूरत से ज़्यादा बारीक लग सकता है। यह इस बात की जाँच करने से सस्ता है कि बिल्ड और पब्लिश के बीच टैग बदला था या एजेंट ने समीक्षक द्वारा जाँची गई पुरानी फ़ाइल के बाद फिर से बनाई गई फ़ाइल अपलोड की थी। इसी जगह थोड़ी रुकावट रिलीज़ कार्य के लिए लाभदायक है।

स्थिर रिलीज़ पर भरोसा करने से पहले जानबूझकर विफलता वाले मामलों के साथ गेट की जाँच करें। एजेंट से अलग SHA वाले ड्राफ्ट को पब्लिश करने को कहें। चेकसम निकालने के बाद किसी आर्टिफैक्ट के बाइट बदल दें। मंज़ूरी के बाद ड्राफ्ट शीर्षक बदलें। तैयारी इंटरफ़ेस के ज़रिए रिलीज़ हटाने का प्रयास करें। हर प्रयास को ऐसे विशिष्ट रिकॉर्ड के साथ विफल होना चाहिए जो ऑपरेटर को कारण बताए।

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