AWS आर्किटेक्चर फैसला रिकॉर्ड के प्रक्रिया
आर्किटेक्चर फैसला रिकॉर्ड (ADR) एगो अइसन दस्तावेज ह जवन कवनो चुनाव के बारे में बतावेला जे टीम सॉफ्टवेयर आर्किटेक्चर के कवनो महत्त्वपूर्ण पक्ष के बारे में करेले, जवन ऊ बनावे के योजना बना रहल बा। हर ADR आर्किटेक्चर फैसला, ओकर संदर्भ, आ ओकर नतीजा के बतावेला। ADR के स्थिति होखेला आ एहसे ऊ जीवनचक्र के पालन करेला। ADR के एगो उदाहरण खातिर, परिशिष्ट देखीं।
ADR प्रक्रिया आर्किटेक्चर फैसला रिकॉर्ड के एगो संग्रह तइयार करेला। ई संग्रह फैसला लॉग बनावेला। फैसला लॉग परियोजना के संदर्भ के साथे-साथे विस्तृत कार्यान्वयन आ डिजाइन के जानकारी देला। परियोजना के सदस्य लोग परियोजना के संदर्भ के सरसरी जानकारी खातिर हर ADR के शीर्षक पर नजर डालेला। परियोजना के कार्यान्वयन आ डिजाइन के चुनाव में गहराई से उतरे खातिर ऊ लोग ADR पढ़ेला।
जब टीम ADR के स्वीकार कर लेले, त ऊ अपरिवर्तनीय हो जाला। अगर नया समझ के चलते अलग फैसला के जरूरत होखे, त टीम नया ADR के प्रस्ताव देले। जब टीम नया ADR स्वीकार कर लेले, त ऊ पिछला ADR के जगह ले लेला।
ADR प्रक्रिया के दायरा
परियोजना के सदस्य लोग के हर ओह आर्किटेक्चर के लिहाज से महत्त्वपूर्ण फैसला खातिर ADR बनावे के चाहीं जे सॉफ्टवेयर परियोजना चाहे उत्पाद पर असर डालेला, जवना में ई सब शामिल बा (Richards आ Ford 2020):
बनावट (उदाहरण खातिर, माइक्रोसर्विस जइसन पैटर्न)
गैर-कार्यात्मक जरूरत (सुरक्षा, उच्च उपलब्धता, आ दोष सहनशीलता)
निर्भरता (कंपोनेंट के जुड़ाव)
इंटरफेस (API आ प्रकाशित अनुबंध)
निर्माण तकनीक (लाइब्रेरी, फ्रेमवर्क, औजार, आ प्रक्रिया)
कार्यात्मक आ गैर-कार्यात्मक जरूरत ADR प्रक्रिया के सबसे आम इनपुट हवे।
ADR के सामग्री
जब टीम ADR के जरूरत पहचानेले, त टीम के एगो सदस्य परियोजना भर के टेम्पलेट के आधार पर ADR लिखल शुरू करेला। (उदाहरण टेम्पलेट खातिर ADR GitHub संगठन देखीं।) टेम्पलेट ADR बनावल आसान बनावेला आ पक्का करेला कि ADR सब प्रासंगिक जानकारी दर्ज करे। कम से कम, हर ADR के फैसला के संदर्भ, खुद फैसला, आ परियोजना आ ओकर डिलिवरेबल खातिर फैसला के नतीजा परिभाषित करे के चाहीं। (एह खंड के उदाहरण खातिर, परिशिष्ट देखीं।) ADR ढाँचा के सबसे ताकतवर पक्ष में से एक ई बा कि ई फैसला के कारण पर ध्यान देवेला, ना कि एह पर कि टीम ओकरा के कइसे लागू कइलस। टीम ई फैसला काहे कइलस, ई समझला से दोसर टीम सदस्य खातिर फैसला अपनावल आसान हो जाला, आ ऊ आर्किटेक्ट लोग के जे फैसला लिहे के प्रक्रिया में शामिल ना रहले, आगे चल के ओह फैसला के पलटे से रोकेला।
ADR अपनावे के प्रक्रिया
हर टीम सदस्य ADR बना सकेला, लेकिन टीम के ADR खातिर स्वामित्व के परिभाषा तय करे के चाहीं। हर लेखक जे ADR के मालिक हवे, ओकरा ADR के सामग्री के सक्रिय रूप से संभाले आ बतावे के चाहीं। ई स्वामित्व साफ करे खातिर, ई मार्गदर्शिका आगे के खंड में ADR के लेखक सभ के ADR मालिक कहेले। आउर टीम सदस्य हमेशा ADR में योगदान कर सकेले। अगर टीम के ADR स्वीकार करे से पहिले ओकर सामग्री बदल जाए, त मालिक के ई बदलाव मंजूर करे के चाहीं।
जब टीम आर्किटेक्चर फैसला आ ओकर मालिक के पहचान लेले, त ADR के मालिक प्रक्रिया के शुरू में ADR के प्रस्तावित स्थिति में देला। प्रस्तावित स्थिति वाला ADR समीक्षा खातिर तइयार बा।
फेर ADR के मालिक ADR के समीक्षा प्रक्रिया शुरू करेला। ADR समीक्षा प्रक्रिया के लक्ष्य ई तय करे के बा कि टीम ADR के स्वीकार करेले, ई निर्धारित करेले कि ओकरा में फेर से काम के जरूरत बा, चाहे ADR के खारिज कर देले। परियोजना टीम, मालिक के साथे, ADR के समीक्षा करेले। समीक्षा बैठक के ADR पढ़े खातिर समर्पित समय से शुरू होखे के चाहीं। औसतन, 10 से 15 मिनट काफी होखे के चाहीं। एह दौरान, हर टीम सदस्य दस्तावेज पढ़ेला आ अस्पष्ट विषय के चिह्नित करे खातिर टिप्पणी आ सवाल जोड़ेला। समीक्षा चरण के बाद, ADR के मालिक हर टिप्पणी के पढ़ के सुनावेला आ टीम संगे ओकरा पर बतकही करेला।
अगर टीम ADR में सुधार खातिर कार्रवाई बिंदु पावेले, त ADR के स्थिति प्रस्तावित ही रहेला। ADR के मालिक कार्रवाई तइयार करेला, आ टीम के सहयोग से, हर कार्रवाई में एगो जिम्मेदार जोड़ेला। हर टीम सदस्य कार्रवाई बिंदु में योगदान आ ओकर समाधान कर सकेला। समीक्षा प्रक्रिया के फेर से तय करे के जिम्मेदारी ADR के मालिक के बा।
टीम ADR के खारिज करे के फैसला भी कर सकेले। एह मामला में, ADR के मालिक आगे ओही विषय पर बहस रोके खातिर खारिज करे के कारण जोड़ेला। मालिक ADR के स्थिति खारिज में बदल देला।
अगर टीम ADR के मंजूर कर देले, त मालिक टाइमस्टैंप, संस्करण, आ हितधारक के सूची जोड़ेला। फेर मालिक स्थिति के स्वीकार में अपडेट कर देला।
ADR आ ओकर बनावल फैसला लॉग टीम के कइल फैसला के दर्शावेला आ सब फैसला के इतिहास देला। जहाँ संभव होखे, टीम कोड आ आर्किटेक्चर समीक्षा के दौरान ADR के संदर्भ के रूप में इस्तेमाल करेले। कोड समीक्षा, डिजाइन के काम, आ कार्यान्वयन के काम करे के अलावा, टीम सदस्य लोग के उत्पाद के रणनीतिक फैसला खातिर ADR देखे के चाहीं।
एगो नीमन अभ्यास के रूप में, हर सॉफ्टवेयर बदलाव के सहकर्मी समीक्षा से गुजरे के चाहीं आ कम से कम एक मंजूरी के जरूरत होखे के चाहीं। कोड समीक्षा के दौरान, कोड समीक्षक के अइसन बदलाव मिल सकेला जे एक चाहे जादा ADR के उल्लंघन करेला। एह मामला में, समीक्षक कोड बदलाव के लेखक से कोड अपडेट करे के कहेला, आ ADR के लिंक साझा करेला। जब लेखक कोड अपडेट कर देला, त सहकर्मी समीक्षक ओकरा के मंजूर करेले आ मुख्य कोड आधार में मिला दिहल जाला।
ADR समीक्षा के प्रक्रिया
टीम के ADR के स्वीकार चाहे खारिज करे के बाद ओकरा के अपरिवर्तनीय दस्तावेज मानल चाहीं। मौजूदा ADR में बदलाव खातिर नया ADR बनावे, नया ADR खातिर समीक्षा प्रक्रिया बनावे, आ ADR के मंजूर करे के जरूरत होखेला। अगर टीम नया ADR के मंजूर कर देले, त मालिक के पुरान ADR के स्थिति बदलल गइल में बदल देवे के चाहीं।