प्रमाण के साथ Taiga delivery का review करें
पूरा हुआInitiative, plan, run, diff और checks जोड़ें। Merge या release स्वीकार करने से पहले वर्तमान बदलाव जाँचें।
प्रकाशक Taigaहम कैसे लिखते हैं
अपनी समझ जाँचेंRun पूरा हुआ, लेकिन record कहता है कि required test नहीं चला। Completion क्या सिद्ध करती है?अभ्यास करें
आप क्या सीखेंगे
- Delivered behavior को उसकी requirement और plan तक trace करें।
- अधूरी checks और review माँगने वाली धारणाएँ पहचानें।
- Run completion, merge, deployment और उपयोगकर्ताओं के लिए software की उपलब्धता का अंतर समझें।
Initiative के परिणाम से शुरू करें
काल्पनिक equipment service अब employees को अपने requests देखने देती है। Initiative के outcome और scope से review शुरू करें। पहचानें कि क्या सही होना चाहिए और बदलाव को क्या सुरक्षित रखना चाहिए।
इस delivery में employee दूसरे employee का request नहीं पढ़ सकता। Managers का तय access बना रहना चाहिए। केवल page खोलने वाला test दोनों में से कोई शर्त सिद्ध नहीं करता।
Records जोड़ें
| Record | Review का प्रश्न |
|---|---|
| Initiative | कौन-सा परिणाम और दायरा अधिकृत था? |
| Plan version | कौन-से implementation और verification चरण तय थे? |
| Run | क्या हुआ और agent ने कौन-सी धारणाएँ बनाईं? |
| Pull request और diff | Current commit में क्या बदला? |
| Checks और review | उस commit की स्वीकृति को कौन-सा प्रमाण समर्थन देता है? |
| Deployment record | कौन-सा artifact किस environment पहुँचा? |
Runs page असफलताओं समेत प्रयास दर्ज करता है। हर run execute किए plan को पहचानता है। Run page निरीक्षण का record है; काम बदलने वाले निर्णय initiative पर होते हैं।
Tests और formatting के step evidence पढ़ें। Taiga failed या न चली checks स्पष्ट करता है। Review summary में “नहीं चला” को “pass” न बनाएँ।
धारणाएँ और सीमाएँ जाँचें
Access model, schema, environment और external services की धारणाएँ देखें। Published intent और वास्तविक code से तुलना करें।
Equipment service में देखें कि request owner कहाँ जाँचा जाता है। अधिकृत request, दूसरे employee का request और missing request जाँचें। सुनिश्चित करें कि logs गोपनीय request content उजागर नहीं करते।
Test changes भी review करें। Defect पकड़ने वाला assertion ही हट गया हो तो passing result की उपयोगिता सीमित है। Workflow और test-configuration changes review के दायरे में रखें।
कार्रवाई योग्य feedback दें
व्यवहार, अपेक्षित परिणाम और जरूरी प्रमाण बताएँ। उदाहरण: “Endpoint login जाँचता है, request ownership नहीं। Server-side access check और दूसरे employee का request इस्तेमाल करने वाला test जोड़ें।”
Taiga pull-request review feedback और failing checks पर उसी branch में बदलाव कर सकता है। Updates के बाद नया commit और checks देखें। पहले का प्रमाण बदला artifact cover न भी करे।
Plan अधूरा होने या check कमजोर होने से run रुका हो तो बताया कारण पढ़ें। केवल visible check summary हरी होने से draft status न हटाएँ।
सही acceptance निर्णय लें
कौन-से criteria verified हैं और कौन-से unresolved, यह दर्ज करें। Repository के required reviews और checks को merge सीमा लागू करने दें। अलग release decision हो तो बनाए रखें।
Taiga आपकी pipeline के deployments observe करता है। Users को बदलाव उपलब्ध बताने से पहले environment और artifact जाँचें। Failed deployment के बाद पिछला successful version traffic सँभालता रह सकता है।
Service-level check से परिणाम पूरा करें: employee feature इस्तेमाल कर सके, unauthorized access denied हो और operational owner failures देख सके। आगे रुकावट सँभालना पढ़ें।
अभ्यास करें
काल्पनिक employee-access change का build pass है और run note कहता है कि integration test नहीं चल सका। स्वीकार करने से पहले जरूरी प्रमाण लिखें। एक denied-access case और review वाला सटीक artifact या commit शामिल करें।
Worksheet डाउनलोड करें (Markdown)यह चयन हटाने से इस browser में सहेजी गई पूरी प्रगति मिट जाती है।
प्रगति इसी browser में रहती है। कोई account या tracking नहीं।