बिल्ड लाइट इंडिकेटर: Difference between revisions
No edit summary |
No edit summary |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 22: | Line 22: | ||
==संदर्भ== | ==संदर्भ== | ||
{{Reflist|colwidth=35em}} | {{Reflist|colwidth=35em}} | ||
[[Category:All articles with unsourced statements]] | |||
[[Category:Articles with unsourced statements from April 2017]] | |||
[[Category: | |||
[[Category:Created On 25/06/2023]] | [[Category:Created On 25/06/2023]] | ||
[[Category:Machine Translated Page]] | |||
[[Category:Pages with script errors]] | |||
[[Category:Templates Vigyan Ready]] | |||
[[Category:Webarchive template wayback links]] | |||
[[Category:चुस्त सॉफ्टवेयर विकास]] | |||
Latest revision as of 07:53, 15 July 2023
बिल्ड-लाइट सूचक एक सरल दृश्य संकेतक है जिसका उपयोग एजाइल सॉफ्टवेयर विकास में सॉफ्टवेयर विकासक के एक समूह को उनकी योजना की वर्तमान स्थिति के विषय में सूचित करने के लिए किया जाता है। जिसमे उपयोग की जाने वाली वास्तविक वस्तु का दाब मापने के यंत्र से लेकर लावा लैंप तक भिन्न हो सकती है, लेकिन इसका उद्देश्य त्वरित रूप से यह प्रदर्शित करना है कि कोई सॉफ़्टवेयर प्रक्रिया सफल है या सफल नहीं है।
इतिहास
बिल्ड-लाइट सूचक की उत्पत्ति थॉटवर्क्स के कर्मचारियों द्वारा बनाए गए एक सतत एकीकरण उपकरण क्रूज़ नियंत्रण से हुई है।[citation needed] हालाँकि यह मुख्य रूप से एक वेब पेज डैशबोर्ड के रूप में कार्य करता है जो किसी बिल्ड-लाइट के विषय में अधिक विस्तृत जानकारी साझा कर सकता है, सॉफ्टवेयर सरल रिपोर्टिंग के लिए बाहरी उपकरणों को भी नियंत्रित कर सकता है।[1]
उपयोग
बिल्ड-लाइट का पारंपरिक उपयोग निरंतर एकीकरण (सीआई) प्रणाली में सॉफ़्टवेयर निर्माण की सफलता का निर्धारण करना है।[2] विभिन्न विकास समूहों ने अलग-अलग संकेतकों का उपयोग किया है लेकिन एक लोकप्रिय विकल्प हरा और लाल लावा लैंप है जब निर्माण सफल होता है तो हरा और कुछ गलत होने पर लाल होता है।[3] बिल्ड-लाइट वेबकैम या अन्य माध्यमों से दूर से भी अभिगम्य योग्य हो सकता हैं।[4] हालाँकि नवीनतम परिवर्तनों के बाद व्यस्त विकास विभागों में कई परीक्षण सदैव पुन: परीक्षण की स्थिति में होते है और कुछ संकेतकों में तीन स्थितियाँ उत्तीर्ण, अनुउत्तीर्ण विभागों के लिए अधिक सूक्ष्म संकेत प्रबंधक प्रदान करने के लिए पुन: परीक्षण किया जा रहा है।[2][5]
एकल संकेतकों के अतिरिक्त
निरंतर एकीकरण से लेकर निरंतर परीक्षण तक की वृद्धि के साथ एकल कोडबेस के लिए भी एक साथ निर्माण लक्ष्यों की संख्या बढ़ सकती है। एक सरल निर्माण (अर्थात संकलन) लक्ष्य के साथ-साथ इकाई परीक्षण और प्रणाली परीक्षण के विभिन्न स्तर हो सकते है चूँकि व्यापक परीक्षण अपेक्षाकृत धीमे होते हैं और विकासक को त्वरित प्रतिक्रिया देने के लिए तीव्र चक्र पर तीव्र परीक्षण चलाना वांछनीय है। निर्माण लक्ष्यों की संख्या 50 या अधिक तक बढ़ सकती है। साधारण लावा लैंप प्रदर्शनी के साथ दिखाने के लिए यह बहुत अधिक है जेनकिंस जैसे एकीकरण सर्वर एक वेब-सुलभ डैशबोर्ड पेज प्रदान करते हैं और इसके अतिरिक्त दीवार पर लगे समतल स्क्रीन मॉनिटर पर स्थायी रूप से प्रदर्शित किया जा सकता है। ऐसे डैशबोर्ड का विवरण किसी विभाग में पढ़ने के लिए अपेक्षाकृत बहुत छोटा है लेकिन रंग परिवर्तन स्थिति की समग्र छवि को प्रस्तुत करता है।
निरंतर परीक्षण-संचालित विकास पद्धति के साथ नए परीक्षणों को पास करने के लिए कार्यशील कोड विकसित करने से पहले प्रस्तुत किया जाता है। इस प्रकार एक अवधि होती है जब कुछ परीक्षण ज्ञात होते हैं और वास्तव में उनका विफल होना आवश्यक होता है और असफल परीक्षणों की आवश्यकता होती है क्योंकि वे चिंता की स्थिति का पता लगाने के लिए नए परीक्षणों की क्षमता को प्रदर्शित करते हैं।[6] एक बार जब नया कोड विकसित हो जाता है और कार्य करने लगता है तो ये परीक्षण पास होने लगते हैं। जिससे निरंतर परीक्षण वातावरण जिसमें नए परीक्षण उनके कोड से पहले प्रारम्भ किए जाते हैं, इस प्रकार दो निर्माण लक्ष्यों की आवश्यकता होती है जो एक नवीनतम कोड और परीक्षणों को टनियंत्रित करता है, दूसरा 'प्रकाशन प्रार्थक' केवल वेतन वृद्धि में अपडेट किया जाता है जब सभी परीक्षण कोड उत्तीर्ण करके पूरे हो जाते हैं। निर्मित सूचक के लिए इसका तात्पर्य यह भी है कि उन लक्ष्यों में से एक को प्रायः उसके परीक्षणों में "असफल" के रूप में दिखाया जाएगा। चूँकि यह प्रत्याशित "विफलता" सामान्य दर्शकों के लिए भ्रामक होगी, निर्माण संकेतक को या तो इसे छिपाना चाहिए या इसे स्पष्ट रूप से प्रस्तुत करना चाहिए।
जहां कई कोड लक्ष्य जैसे पुराने उत्पाद संस्करण अभी भी सीआई के लिए समर्थित हैं लेकिन ऐसे सक्रिय विकास के अंतर्गत नहीं हैं, तो एक पूर्ण डैशबोर्ड "पुराने" लक्ष्यों पर प्रभावी हो सकता है जो लगभग ही कभी परिवर्तित होते हैं। इस स्थिति में एक चयनित डैशबोर्ड अधिक उपयुक्त हो सकता है, जहां केवल वे लक्ष्य प्रदर्शित होते हैं जो या तो विफल हो रहे हैं या हाल ही में सक्रिय हो रहे हैं और संपूर्ण डैशबोर्ड विकासक के डेस्कटॉप के लिए उपलब्ध है, लेकिन प्रदर्शनी केवल महत्वपूर्ण हाइलाइट्स दिखाती है। ऐसे डैशबोर्ड को प्रायः स्थानीय आवश्यकताओं के अनुसार मुख्य डैशबोर्ड को स्क्रीन-स्क्रैप करके और उस पर प्रासंगिक स्थानीय फ़िल्टर प्रयुक्त करके स्थानीय रूप से कोडित किया जाता है। स्थिर डैशबोर्ड की तुलना में डायनामिक फ़िल्टर डैशबोर्ड का एक दोष यह है कि किसी विशेष लक्ष्य के लिए आइकन की स्थिति स्क्रीन पर परिवर्तित हो सकती है। जिससे समग्र विभाग को पढ़ना जटिल हो जाता है। इस स्थिति में साधारण रंग ब्लॉकों के अतिरिक्त 'उत्पाद लोगो' जैसे विशिष्ट चिह्न प्रदर्शित किए जा सकते हैं।
संदर्भ
- ↑ Mike Cohn (10 July 2009). Succeeding with Agile: Software Development Using Scrum. Pearson Education. pp. 245–. ISBN 978-0-321-57936-2. Retrieved 23 August 2011.
- ↑ 2.0 2.1 "ओर्ब - संकेतक लैंप बनाएं". agileskunkworks.org. Archived from the original on June 11, 2010.
- ↑ Ken W. Collier (27 July 2011). Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing. Addison-Wesley. pp. 281–. ISBN 978-0-321-50481-4. Retrieved 23 August 2011.
- ↑ Karsten, Paul; Cannizzo, Fabrizzio (2007). "एक वितरित चुस्त टीम का निर्माण". XP'07 Proceedings of the 8th International Conference on Agile Processes in Software Engineering and Extreme Programming. Lecture Notes in Computer Science. Association for Computing Machinery. 4536: 235–239. doi:10.1007/978-3-540-73101-6_44. ISBN 978-3-540-73100-9.
- ↑ Build Light – Continuous Delivery meets Reengineering an[sic USB driver] Archived September 15, 2013, at the Wayback Machine - Bernd Zuther, comSysto GmbH, 2013
- ↑ Madeyski, L.; Kawalerowicz, M. (4–6 July 2013). Continuous Test-Driven Development - A Novel Agile Software Development Practice and Supporting Tool. Proc. 8th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE). Angers, France. p. 262.
