GitHub, Confluence और Jira में AI प्रकाशन कार्यप्रवाह

AI सहयोग पाठ्यक्रम पर लौटें

मालिकों की स्वीकृति से पहले योगदानकर्ता PROP-042 को स्थिर करता है। Confluence प्रकाशक आवश्यकताएँ अपडेट करता है, GitHub अनुरक्षक कार्यान्वयन मर्ज करता है और ऑपरेशंस रनबुक प्रकाशित करता है। Jira हर चरण दर्ज करता है। अनुमति जाँचने के बाद यह करें, क्योंकि तीनों प्रणालियाँ मिलकर एक परमाणु लेन-देन नहीं बनातीं। आपका प्रकाशन लेजर अधूरी डिलीवरी को स्पष्ट करता है।

मुख्य बातें #

• स्वीकृत मंशा और डिलीवर किया गया व्यवहार अलग हैं।
• निश्चित प्रस्ताव संशोधन समीक्षा को किसी खास संस्करण से जोड़ते हैं।
• प्रकाशन लेजर अधूरे काम को दिखाते हैं।
• नए स्रोत-पाठ बदले हुए आधार से सुरक्षा देते हैं।

शुरू करने से पहले #

पूर्वापेक्षाएँ: कार्यस्थल सेटअप , प्रकाशन पहुँच, मालिक और रिपॉज़िटरी अनुरक्षक। अनुमानित समय: दो घंटे। कठिनाई: उन्नत समन्वय।

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

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

मौजूदा स्रोत दर्ज करें #

1. MAP-01 पढ़ें, फिर मैप किए गए पेज ID से REQ-17 और RUN-04 खोलें।
2. पेज मेनू और Page History खोलें, फिर संख्यात्मक संस्करण, स्थिति, शब्दावली, मालिक और अपवाद दर्ज करें।
3. Jira आइटम पढ़ें और प्रस्ताव का निश्चित एक्सपोर्ट या GitHub commit संलग्न करें। केवल कुंजी समीक्षा के प्रमाण को स्थिर नहीं करती।
4. स्वीकृत POL-01 और सुरक्षित कॉन्फ़िगरेशन आधार पढ़ें।
5. चैट को केवल आवश्यक सिंथेटिक अंश दें, उन्हें स्नैपशॉट चिह्नित करें और लेखन-सक्षम कार्रवाइयाँ बंद रखें।

Task: PROP-042, propose only
Authority: Confluence REQ-17 for intent, GitHub for behavior
Read: mapped current pages, versions, scope, exceptions
Proposal: synthetic export retention from 7 to 30 days
Output: requirement wording, config diff, runbook, ledger
Evidence: source ID and captured revision for each factual claim
Unknowns: missing access and absent runtime observations
Stop: conflict, changed base, or denied access

ऑफ़लाइन पैकेट स्नैपशॉट पर आधारित रहते हैं। लिखने से पहले प्रकाशक मौजूदा स्रोत फिर पढ़ता है। पहुँच अस्वीकृत होने पर प्रकाशन रुकता है। पुराना एक्सपोर्ट मौजूदा प्राधिकरण का विकल्प नहीं है।

प्रस्ताव स्थिर करें #

{
  "proposal_id": "PROP-042",
  "proposal_revision": 1,
  "requirement_base_version": 1,
  "runbook_base_version": 1,
  "policy_version": 1,
  "from_days": 7,
  "to_days": 30,
  "status": "awaiting-owner-review",
  "publication_order": ["requirement", "implementation", "runbook", "delivery"]
}

उदाहरण वाले पेज संस्करणों को वास्तव में दर्ज किए गए संस्करणों से बदलें। निश्चित JSON और प्रस्तावित शब्दावली Jira में संलग्न करें। हर मालिक अपनी भूमिका, निर्णय, प्रस्ताव संशोधन, स्रोत संस्करण और समीक्षा समय दर्ज करता है। कोई भी महत्वपूर्ण बदलाव पैकेज को Review में लौटाता है।

प्रोडक्ट मंशा और दायरे की समीक्षा करता है। ऑपरेशंस सफ़ाई और पुनर्प्राप्ति की समीक्षा करता है। अनुरक्षक diff की समीक्षा करता है। बदल सकने वाले चैट संदेशों पर प्रतिक्रियाएँ किसी निश्चित संशोधन से बँधी स्वीकृति नहीं हैं।

प्रकाशित करें और फिर पढ़ें #

1. प्रकाशक दोनों मालिकों की समीक्षा और अपरिवर्तित स्रोत आधार जाँचने के बाद Jira को Publishing में ले जाता है।
2. REQ-17 प्रकाशित करें जिसमें तीस दिन और डिलीवरी लंबित फ़ील्ड हो। बना हुआ संस्करण, दायरा और अपवाद दर्ज करें।
3. GitHub कार्यान्वयन PR खोलें, स्वीकृत पेज संस्करण का संदर्भ दें। कॉन्फ़िगरेशन को तीस दिन पर बदलें और गैर-प्रामाणिक आवश्यकता स्नैपशॉट संलग्न करें।
4. रिपॉज़िटरी समीक्षा के बाद मर्ज करें और main को फिर पढ़ें। रिपॉज़िटरी में दर्ज व्यवहार को रनटाइम व्यवहार से अलग दर्ज करें।
5. RUN-04 प्रकाशित करें, ID से फिर पढ़ें और बना हुआ संस्करण दर्ज करें। प्रकाशक आवश्यकता के डिलीवरी संदर्भ अपडेट करता है।
6. Jira तभी पूरा करें जब सभी रिकॉर्ड मेल खाएँ और अंतिम दोबारा पढ़ने का प्रमाण संलग्न हो।

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

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

आंशिक प्रकाशन दर्ज करें #

अगला चरण शुरू करने से पहले हर परिणाम दर्ज करें। PROP-042 अलग-अलग प्रणालियों की घटनाएँ जोड़ता है। एक पूरी पंक्ति का अर्थ पूरा बदलाव नहीं है।

विफलता का उदाहरण: Confluence तीस दिन प्रकाशित करता है, लेकिन GitHub मर्ज अस्वीकार करता है। Jira को Blocked रखें और आवश्यकता को डिलीवरी लंबित चिह्नित करें। प्रोडक्ट टीम बदलाव आगे पूरा करने या समीक्षा के बाद सात दिन पर लौटने का निर्णय लेती है। आपातकालीन README प्रति को आवश्यकता का प्राधिकरण न बनाएँ।

साथ-साथ हुए बदलाव संभालें #

ब्राउज़र आधार: पायलट अवधि में एक प्रकाशक नियुक्त करें। संपादन से ठीक पहले और प्रकाशन के बाद Page History फिर खोलें। दूसरा लेखक स्रोत बदले तो रुकें, तुलना करें, समाधान करें और स्वीकृति नवीनीकृत करें। क्रमबद्ध प्रकाशन एक प्रक्रिया है, परमाणु लेन-देन की गारंटी नहीं।

API विस्तार: Confluence v2 दस्तावेज़ GET /wiki/api/v2/pages/{id}?body-format=storage और संस्करण ऑब्जेक्ट वाला PUT /wiki/api/v2/pages/{id} बताते हैं। समीक्षा किया प्रकाशक एकीकरण मौजूदा संस्करण की स्वीकृत आधार से तुलना करता है, अगला संस्करण भेजता है और फिर पढ़ता है। विफल संस्करण को अपने-आप रीफ़्रेश करके पुराना बॉडी फिर कभी न भेजें।

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

नकारात्मक मामलों की जाँच करें #

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

समीक्षा पैकेज बनाएँ #

केवल प्रस्ताव लेबल नहीं, पूरा कंटेंट स्थिर करें। PROP-042 हर प्रणाली में दिखता है, लेकिन लेबल यह नहीं बताता कि मालिक ने कौन-सा बॉडी देखा था। सटीक आवश्यकता शब्दावली, कार्यान्वयन diff, रनबुक शब्दावली, स्रोत संस्करण और प्रकाशन क्रम एक निश्चित पैकेज में रखें।

Package: PROP-042 revision 1, illustrative
Intent: synthetic export retention changes from 7 to 30 days
Exclusions: production data, backups, legal holds
Requirement amendment: fixed proposed REQ-17 wording
Implementation: fixed candidate diff and protected base reference
Runbook amendment: fixed RUN-04 wording and recovery limits
Review: product and operations decisions for this package
Delivery: requirement -> implementation -> runbook -> closure
Stop: changed source, missing review, denied write, failed read-back

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

इस सिंथेटिक उदाहरण के लिए भरा हुआ पैकेज:

REQ-17 proposed v5: "Synthetic export files are retained for 30 days from creation. This pilot excludes production data, backups, and legal holds. Delivery remains pending until the GitHub configuration and RUN-04 read-backs match this approved wording."

GitHub config.json, proposed change against base-001:
-  "retention_days": 7
+  "retention_days": 30

RUN-04 proposed v3: "Retention days: 30. Synthetic exports only. No deletion job runs in this lab. If publication fails, keep delivery pending, read back each source, and obtain owner approval before restoring the seven-day configuration or completing the thirty-day publication."

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

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

लेजर पर चलें #

उदाहरण स्थिति क्रम: तालिका में शिक्षण संशोधन हैं, अवलोकन नहीं। हर सैंडबॉक्स लेखन के बाद वास्तविक बने संस्करण और commit भरें।

डिलीवरी लंबित एक अर्थपूर्ण स्थिति है। यह अधूरे प्रकाशन के दौरान पुराने कार्यान्वयन को नई मंशा के अनुरूप बताने से रोकती है। इस अवधि में पाठकों को दोनों मान चाहिए, ऐसा एक सारांश नहीं जो कहे कि प्रतिधारण अब तीस दिन है।

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

पुराने संस्करण अस्वीकार होने का उदाहरण: प्रकाशक REQ-17 v4 पढ़ता है, कोई अन्य अधिकृत संपादक v5 प्रकाशित करता है, फिर प्रकाशक v4 पर PROP-042 r1 लागू करने का प्रयास करता है। प्लेटफ़ॉर्म संस्करण टकराव दिखाता है, या लिखने से पहले की जाँच v5 देखती है। अभिनेता publisher, शुरुआती v4, प्रयास PROP-042 r1, देखा गया टकराव या बदला वर्तमान संस्करण, इस प्रयास से अपरिवर्तित अंतिम v5 और सौंपा गया मालिक product owner दर्ज करें। Jira को Review में रखें। v5 फिर पढ़ें, शब्दावली मिलाएँ और दोबारा लिखने से पहले नए निश्चित पैकेज की समीक्षा लें। लाइव परीक्षण में वास्तविक प्लेटफ़ॉर्म उत्तर और Page History इस्तेमाल करें। यह पंक्ति शिक्षण उदाहरण है।

पूरा शिक्षण उदाहरण, केवल सिंथेटिक मान:

ऊपर के लेबल उदाहरण हैं, टेनेंट प्रमाण नहीं। आपके लेजर में मूल पेज-संस्करण लिंक और commit ID चाहिए। Jira को Done करने से पहले स्थिर प्रस्ताव, दोनों भूमिका-समीक्षाएँ, स्रोत-आधार रिकॉर्ड, हर प्रकाशन की दोबारा पढ़ाई, नकारात्मक परीक्षण का परिणाम और अनसुलझी रनटाइम सीमाएँ संलग्न करें। कुछ भी गायब हो तो डिलीवरी खुली या Blocked रखें।

पैकेज गेट: पाँचों जाँच को Supported या Blocked चिह्नित करें: स्रोत संशोधन नए हैं, दोनों मालिकों ने उसी निश्चित संशोधन को अनुमोदित किया, सभी आवश्यक प्रकाशन दोबारा पढ़े परिणाम से मेल खाते हैं, रनटाइम सीमाएँ स्पष्ट हैं और पुनर्प्राप्ति स्थिति मिलाई गई है। Done के लिए पाँच Supported जाँच और कोई अनधिकृत लेखन नहीं चाहिए।

अनिश्चित लेखन संभालें #

टाइमआउट से परिणाम अज्ञात रहता है। इससे सफलता या विफलता साबित नहीं होती। ब्राउज़र आधार में दोबारा प्रयास करने से पहले मैप किए स्रोत को खोलें और उसकी मौजूदा सामग्री तथा इतिहास देखें।

1. अगला चरण रोकें: डिलीवरी अधूरी रखें।
2. गंतव्य पढ़ें: मौजूदा शब्दावली, संस्करण और दायरे की निश्चित पैकेज से तुलना करें।
3. अवलोकन दर्ज करें: पूरा, अपरिवर्तित, टकराव वाला या पहुँच से बाहर।
4. अगली कार्रवाई चुनें: सत्यापित पूर्ण स्थिति से जारी रखें, अधिकृत अपरिवर्तित चरण फिर आज़माएँ या टकराव आगे बढ़ाएँ।
5. अनिश्चितता बनाए रखें: विफल/अज्ञात प्रयास को बाद की दोबारा पढ़ाई के साथ रखें।

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

पुनर्प्राप्ति निर्णयों की तुलना करें #

मौजूदा स्थिति और मालिक के निर्णय के अनुसार चुनें। आगे बढ़ने के लिए मौजूदा स्वीकृति और काम करने वाले नियंत्रण चाहिए। भरपाई के लिए बीच के बदलावों के संदर्भ में बहाली की समीक्षा चाहिए। पुनर्प्राप्ति बदलाव एक और प्रकाशन है, प्रक्रिया का विशेष अपवाद नहीं।

प्रकाशन पूर्णता जाँच #

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

अपेक्षित तर्क: अगला काम नए स्रोतों और लेजर से तय होता है, पिछले सहायक के भरोसे से नहीं। अंतिम मैप किए संदर्भ retrieval परीक्षणों में ले जाएँ, जहाँ खोज को वही प्राधिकरण अंतर बनाए रखना चाहिए।

समस्या निवारण और पुनर्प्राप्ति #

संस्करण बदल गया: इतिहास की तुलना करें और समीक्षा नवीनीकृत करें। स्नैपशॉट जाँच सफल, पर wiki अलग: मौजूदा Confluence स्रोत फिर लाएँ। Done जल्दी हुआ: अनुमत कार्यप्रवाह से फिर खोलें और छूटे चरण दर्ज करें।

पुनर्प्राप्ति: Page History तुलना और मालिक-समीक्षित बहाली या प्रतिपूरक संपादन करें। यह न मानें कि बहाली क्रमांक वापस करती है, बना हुआ संस्करण दर्ज करें। प्रोडक्ट वापस लेने का निर्णय करे तो सुरक्षित PR से कॉन्फ़िगरेशन लौटाएँ। हटाई गई फ़ाइलें वापसी की गारंटी से बाहर हैं।

अभ्यास और स्व-जाँच #

REQ-17 प्रकाशन के बाद रुकें और दूसरे प्रकाशक को केवल मैप और लेजर दें।

अपेक्षित तर्क: वह मौजूदा स्रोत लाएगा, निश्चित स्वीकृति की पुष्टि करेगा और केवल अधिकृत लंबित चरण जारी करेगा। प्रमाण गायब हों तो काम Review में लौटेगा।

प्राथमिक संदर्भ #

• इतिहास और बहाली: Confluence तकनीकी दस्तावेज़ .
• संस्करणयुक्त API संचालन: Confluence REST API v2 पेज .
• कार्यप्रवाह नियंत्रण: Jira उन्नत कार्यप्रवाह .
• एकीकरण सुरक्षा: MCP सुरक्षा के सर्वोत्तम तरीके .

अगले कदम #

समीक्षित प्रकाशन अभ्यास पूरा करने के बाद मैप-प्रथम पुनर्प्राप्ति जारी रखें।