बिल्ड लाइट इंडिकेटर: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{notability|date=August 2012}} | {{notability|date=August 2012}} | ||
[[File:Series of build lights.jpg|thumb|वास्तविक निर्माण के | [[File:Series of build lights.jpg|thumb|वास्तविक निर्माण के अतिरिक्त इकाई परीक्षण जैसी प्रक्रियाओं पर प्रयुक्त निर्माण प्रकाशों की एक श्रृंखला]]'''निर्माण प्रकाश सूचक''' एक सरल दृश्य संकेतक है जिसका उपयोग एजाइल [[चुस्त सॉफ्टवेयर विकास|सॉफ्टवेयर विकास]] में [[सॉफ्टवेयर डेवलपर्स|सॉफ्टवेयर विकासक]] के एक समूह को उनकी योजना की वर्तमान स्थिति के विषय में सूचित करने के लिए किया जाता है। जिसमे उपयोग की जाने वाली वास्तविक वस्तु का दाब मापने के यंत्र से लेकर [[लावा लैंप]] तक भिन्न हो सकती है, लेकिन इसका उद्देश्य त्वरित रूप से यह प्रदर्शित करना है कि कोई सॉफ़्टवेयर प्रक्रिया सफल है या सफल नहीं है। | ||
==इतिहास== | ==इतिहास== | ||
निर्माण प्रकाश सूचक की उत्पत्ति थॉटवर्क्स के कर्मचारियों द्वारा बनाए गए एक सतत एकीकरण उपकरण क्रूज़ नियंत्रण से हुई है।{{Citation needed|date=April 2017}} हालाँकि यह मुख्य रूप से एक वेब पेज डैशबोर्ड के रूप में कार्य करता है जो किसी निर्माण प्रकाश के विषय में अधिक विस्तृत जानकारी साझा कर सकता है, सॉफ्टवेयर सरल रिपोर्टिंग के लिए बाहरी उपकरणों को भी नियंत्रित कर सकता है।<ref name="Cohn2009">{{cite book|author=Mike Cohn|title=Succeeding with Agile: Software Development Using Scrum|url=https://books.google.com/books?id=8IglA6i_JwAC&pg=PT245|accessdate=23 August 2011|date=10 July 2009|publisher=Pearson Education|isbn=978-0-321-57936-2|pages=245–}}</ref> | |||
==उपयोग== | ==उपयोग== | ||
निर्माण प्रकाश का पारंपरिक उपयोग निरंतर एकीकरण (सीआई) प्रणाली में सॉफ़्टवेयर निर्माण की सफलता का निर्धारण करना है।<ref name="Orb">{{cite web|url=http://www.agileskunkworks.org/Articles/TheOrbBuildIndicatorLamp/tabid/114/Default.aspx |title=ओर्ब - संकेतक लैंप बनाएं|work=agileskunkworks.org |url-status=dead|archiveurl=https://web.archive.org/web/20100611004354/http://www.agileskunkworks.org/Articles/TheOrbBuildIndicatorLamp/tabid/114/Default.aspx |archivedate=June 11, 2010 }}</ref> विभिन्न विकास समूहों ने अलग-अलग संकेतकों का उपयोग किया है लेकिन एक लोकप्रिय विकल्प हरा और लाल लावा लैंप है जब निर्माण सफल होता है तो हरा और कुछ गलत होने पर लाल होता है।<ref name="Collier2011">{{cite book|author=Ken W. Collier|title=Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing|url=https://books.google.com/books?id=YMR3HynGQjUC&pg=PA281|accessdate=23 August 2011|date=27 July 2011|publisher=Addison-Wesley|isbn=978-0-321-50481-4|pages=281–}}</ref> निर्माण प्रकाश वेबकैम या अन्य माध्यमों से दूर से भी अभिगम्य योग्य हो सकता हैं।<ref>{{cite journal |url=http://dl.acm.org/citation.cfm?id=1769014 |journal=XP'07 Proceedings of the 8th International Conference on Agile Processes in Software Engineering and Extreme Programming |volume=4536 |pages=235–239 |publisher=[[Association for Computing Machinery]] |year=2007 |isbn=978-3-540-73100-9 |last1=Karsten |first1=Paul |last2=Cannizzo |first2=Fabrizzio |title=एक वितरित चुस्त टीम का निर्माण|doi=10.1007/978-3-540-73101-6_44 |series=Lecture Notes in Computer Science }}</ref> हालाँकि नवीनतम परिवर्तनों के बाद व्यस्त विकास विभागों में कई परीक्षण सदैव पुन: परीक्षण की स्थिति में होते है और कुछ संकेतकों में तीन स्थितियाँ उत्तीर्ण, अनुउत्तीर्ण विभागों के लिए अधिक सूक्ष्म संकेत प्रबंधक प्रदान करने के लिए पुन: परीक्षण किया जा रहा है।<ref name="Orb" /><ref>[http://blog.comsysto.com/2013/09/09/build-light-continuous-delivery-meets-reengineering-an-usb-driver/ Build Light – Continuous Delivery meets Reengineering an[sic] USB driver] {{webarchive |url=https://web.archive.org/web/20130915063407/http://blog.comsysto.com/2013/09/09/build-light-continuous-delivery-meets-reengineering-an-usb-driver/ |date=September 15, 2013 }} - Bernd Zuther, comSysto GmbH, 2013</ref> | |||
=== एकल संकेतकों के अतिरिक्त === | === एकल संकेतकों के अतिरिक्त === | ||
निरंतर एकीकरण से लेकर निरंतर परीक्षण तक की वृद्धि के साथ एकल कोडबेस के लिए भी एक साथ निर्माण लक्ष्यों की संख्या बढ़ सकती है। एक सरल निर्माण (अर्थात संकलन) लक्ष्य के साथ-साथ इकाई परीक्षण और प्रणाली परीक्षण के विभिन्न स्तर हो सकते है चूँकि व्यापक परीक्षण अपेक्षाकृत धीमे होते हैं और विकासक को त्वरित प्रतिक्रिया देने के लिए तीव्र चक्र पर तीव्र परीक्षण चलाना वांछनीय है। निर्माण लक्ष्यों की संख्या 50 या अधिक तक बढ़ सकती है। साधारण लावा लैंप प्रदर्शनी के साथ दिखाने के लिए यह बहुत अधिक | निरंतर एकीकरण से लेकर निरंतर परीक्षण तक की वृद्धि के साथ एकल कोडबेस के लिए भी एक साथ निर्माण लक्ष्यों की संख्या बढ़ सकती है। एक सरल निर्माण (अर्थात संकलन) लक्ष्य के साथ-साथ इकाई परीक्षण और प्रणाली परीक्षण के विभिन्न स्तर हो सकते है चूँकि व्यापक परीक्षण अपेक्षाकृत धीमे होते हैं और विकासक को त्वरित प्रतिक्रिया देने के लिए तीव्र चक्र पर तीव्र परीक्षण चलाना वांछनीय है। निर्माण लक्ष्यों की संख्या 50 या अधिक तक बढ़ सकती है। साधारण लावा लैंप प्रदर्शनी के साथ दिखाने के लिए यह बहुत अधिक है जेनकिंस जैसे एकीकरण सर्वर एक वेब-सुलभ डैशबोर्ड पेज प्रदान करते हैं और इसके अतिरिक्त दीवार पर लगे समतल स्क्रीन मॉनिटर पर स्थायी रूप से प्रदर्शित किया जा सकता है। ऐसे डैशबोर्ड का विवरण किसी विभाग में पढ़ने के लिए अपेक्षाकृत बहुत छोटा है लेकिन रंग परिवर्तन स्थिति की समग्र छवि को प्रस्तुत करता है। | ||
[[निरंतर परीक्षण-संचालित विकास]] पद्धति के साथ नए परीक्षणों को पास करने के लिए कार्यशील कोड विकसित करने से पहले प्रस्तुत किया जाता है। इस प्रकार एक अवधि होती है जब कुछ परीक्षण ज्ञात होते हैं और वास्तव में उनका विफल होना आवश्यक होता है और असफल परीक्षणों की आवश्यकता होती है क्योंकि वे चिंता की स्थिति का पता लगाने के लिए नए परीक्षणों की क्षमता को प्रदर्शित करते हैं।<ref>{{Cite conference | [[निरंतर परीक्षण-संचालित विकास]] पद्धति के साथ नए परीक्षणों को पास करने के लिए कार्यशील कोड विकसित करने से पहले प्रस्तुत किया जाता है। इस प्रकार एक अवधि होती है जब कुछ परीक्षण ज्ञात होते हैं और वास्तव में उनका विफल होना आवश्यक होता है और असफल परीक्षणों की आवश्यकता होती है क्योंकि वे चिंता की स्थिति का पता लगाने के लिए नए परीक्षणों की क्षमता को प्रदर्शित करते हैं।<ref>{{Cite conference | ||
| Line 18: | Line 18: | ||
|date=4–6 July 2013 | |date=4–6 July 2013 | ||
|page=262 | |page=262 | ||
}}</ref> एक बार जब नया कोड विकसित हो जाता है और कार्य करने लगता है तो ये परीक्षण पास होने लगते हैं। जिससे निरंतर परीक्षण वातावरण जिसमें नए परीक्षण उनके कोड से पहले प्रारम्भ किए जाते हैं, इस प्रकार दो निर्माण लक्ष्यों की आवश्यकता होती है जो एक नवीनतम कोड और परीक्षणों को टनियंत्रित करता है, दूसरा 'प्रकाशन प्रार्थक' केवल वेतन वृद्धि में अपडेट किया जाता है जब सभी परीक्षण कोड उत्तीर्ण करके पूरे हो जाते हैं। निर्मित सूचक के लिए इसका तात्पर्य यह भी है कि उन लक्ष्यों में से एक को प्रायः उसके परीक्षणों में "असफल" के रूप | }}</ref> एक बार जब नया कोड विकसित हो जाता है और कार्य करने लगता है तो ये परीक्षण पास होने लगते हैं। जिससे निरंतर परीक्षण वातावरण जिसमें नए परीक्षण उनके कोड से पहले प्रारम्भ किए जाते हैं, इस प्रकार दो निर्माण लक्ष्यों की आवश्यकता होती है जो एक नवीनतम कोड और परीक्षणों को टनियंत्रित करता है, दूसरा 'प्रकाशन प्रार्थक' केवल वेतन वृद्धि में अपडेट किया जाता है जब सभी परीक्षण कोड उत्तीर्ण करके पूरे हो जाते हैं। निर्मित सूचक के लिए इसका तात्पर्य यह भी है कि उन लक्ष्यों में से एक को प्रायः उसके परीक्षणों में "असफल" के रूप में दिखाया जाएगा। चूँकि यह प्रत्याशित "विफलता" सामान्य दर्शकों के लिए भ्रामक होगी, निर्माण संकेतक को या तो इसे छिपाना चाहिए या इसे स्पष्ट रूप से प्रस्तुत करना चाहिए। | ||
जहां कई कोड लक्ष्य | जहां कई कोड लक्ष्य जैसे पुराने उत्पाद संस्करण अभी भी सीआई के लिए समर्थित हैं लेकिन ऐसे सक्रिय विकास के अंतर्गत नहीं हैं, तो एक पूर्ण डैशबोर्ड "पुराने" लक्ष्यों पर प्रभावी हो सकता है जो लगभग ही कभी परिवर्तित होते हैं। इस स्थिति में एक चयनित डैशबोर्ड अधिक उपयुक्त हो सकता है, जहां केवल वे लक्ष्य प्रदर्शित होते हैं जो या तो विफल हो रहे हैं या हाल ही में सक्रिय हो रहे हैं और संपूर्ण डैशबोर्ड विकासक के डेस्कटॉप के लिए उपलब्ध है, लेकिन प्रदर्शनी केवल महत्वपूर्ण हाइलाइट्स दिखाती है। ऐसे डैशबोर्ड को प्रायः स्थानीय आवश्यकताओं के अनुसार मुख्य डैशबोर्ड को स्क्रीन-स्क्रैप करके और उस पर प्रासंगिक स्थानीय फ़िल्टर प्रयुक्त करके स्थानीय रूप से कोडित किया जाता है। स्थिर डैशबोर्ड की तुलना में डायनामिक फ़िल्टर डैशबोर्ड का एक दोष यह है कि किसी विशेष लक्ष्य के लिए आइकन की स्थिति स्क्रीन पर परिवर्तित हो सकती है। जिससे समग्र विभाग को पढ़ना जटिल हो जाता है। इस स्थिति में साधारण रंग ब्लॉकों के अतिरिक्त 'उत्पाद लोगो' जैसे विशिष्ट चिह्न प्रदर्शित किए जा सकते हैं। | ||
==संदर्भ== | ==संदर्भ== | ||
Revision as of 11:51, 5 July 2023
 | The topic of this article may not meet Wikipedia's general notability guideline. (August 2012) (Learn how and when to remove this template message) |
निर्माण प्रकाश सूचक एक सरल दृश्य संकेतक है जिसका उपयोग एजाइल सॉफ्टवेयर विकास में सॉफ्टवेयर विकासक के एक समूह को उनकी योजना की वर्तमान स्थिति के विषय में सूचित करने के लिए किया जाता है। जिसमे उपयोग की जाने वाली वास्तविक वस्तु का दाब मापने के यंत्र से लेकर लावा लैंप तक भिन्न हो सकती है, लेकिन इसका उद्देश्य त्वरित रूप से यह प्रदर्शित करना है कि कोई सॉफ़्टवेयर प्रक्रिया सफल है या सफल नहीं है।
इतिहास
निर्माण प्रकाश सूचक की उत्पत्ति थॉटवर्क्स के कर्मचारियों द्वारा बनाए गए एक सतत एकीकरण उपकरण क्रूज़ नियंत्रण से हुई है।[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.
