बिल्ड लाइट इंडिकेटर: Difference between revisions
m (Deepak moved page प्रकाश संकेतक बनाएं to बिल्ड लाइट इंडिकेटर without leaving a redirect) |
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 या अधिक तक बढ़ सकती है। साधारण लावा लैंप प्रदर्शनी के साथ दिखाने के लिए यह बहुत अधिक है। जेनकिंस जैसे एकीकरण सर्वर एक वेब-सुलभ डैशबोर्ड पेज प्रदान करते हैं और इसके अतिरिक्त दीवार पर लगे समतल स्क्रीन मॉनिटर पर स्थायी रूप से प्रदर्शित किया जा सकता है। ऐसे डैशबोर्ड का विवरण किसी विभाग में पढ़ने के लिए अपेक्षाकृत बहुत छोटा है लेकिन रंग परिवर्तन स्थिति की समग्र छवि को प्रस्तुत करता है। | |||
=== एकल संकेतकों | |||
निरंतर एकीकरण से लेकर | |||
[[निरंतर परीक्षण-संचालित विकास]] | [[निरंतर परीक्षण-संचालित विकास]] पद्धति के साथ नए परीक्षणों को पास करने के लिए कार्यशील कोड विकसित करने से पहले प्रस्तुत किया जाता है। इस प्रकार एक अवधि होती है जब कुछ परीक्षण ज्ञात होते हैं और वास्तव में उनका विफल होना आवश्यक होता है और असफल परीक्षणों की आवश्यकता होती है क्योंकि वे चिंता की स्थिति का पता लगाने के लिए नए परीक्षणों की क्षमता को प्रदर्शित करते हैं।<ref>{{Cite conference | ||
|first=L. |last=Madeyski | |first=L. |last=Madeyski | ||
|last2=Kawalerowicz |first2=M. | |last2=Kawalerowicz |first2=M. | ||
| Line 22: | Line 18: | ||
|date=4–6 July 2013 | |date=4–6 July 2013 | ||
|page=262 | |page=262 | ||
}}</ref> | }}</ref> एक बार जब नया कोड विकसित हो जाता है और कार्य करने लगता है तो ये परीक्षण पास होने लगते हैं। जिससे निरंतर परीक्षण वातावरण जिसमें नए परीक्षण उनके कोड से पहले प्रारम्भ किए जाते हैं, इस प्रकार दो निर्माण लक्ष्यों की आवश्यकता होती है जो एक नवीनतम कोड और परीक्षणों को टनियंत्रित करता है, दूसरा 'प्रकाशन प्रार्थक' केवल वेतन वृद्धि में अपडेट किया जाता है जब सभी परीक्षण कोड उत्तीर्ण करके पूरे हो जाते हैं। निर्मित सूचक के लिए इसका तात्पर्य यह भी है कि उन लक्ष्यों में से एक को प्रायः उसके परीक्षणों में "असफल" के रूप '''में दिखाया जाएगा। चूँकि यह प्रत्याशित "विफलता'''" भोले-भाले दर्शकों के लिए भ्रामक होगी, निर्माण संकेतक को या तो इसे छिपाना चाहिए या इसे स्पष्ट रूप से प्रस्तुत करना चाहिए। | ||
जहां कई कोड लक्ष्य, जैसे पुराने उत्पाद संस्करण, अभी भी सीआई के लिए समर्थित हैं, लेकिन ऐसे सक्रिय विकास के तहत नहीं हैं, तो एक पूर्ण डैशबोर्ड पुराने लक्ष्यों पर हावी हो सकता है जो शायद ही कभी बदलते हैं। इस मामले में एक चयनित डैशबोर्ड अधिक उपयुक्त हो सकता है, जहां केवल वे लक्ष्य प्रदर्शित होते हैं जो या तो विफल हो रहे हैं, या हाल ही में सक्रिय हैं। संपूर्ण डैशबोर्ड डेवलपर के डेस्कटॉप के लिए उपलब्ध है, लेकिन वॉल डिस्प्ले केवल महत्वपूर्ण हाइलाइट्स दिखाता है। ऐसे डैशबोर्ड को अक्सर स्थानीय आवश्यकताओं के अनुसार मुख्य डैशबोर्ड को | जहां कई कोड लक्ष्य, जैसे पुराने उत्पाद संस्करण, अभी भी सीआई के लिए समर्थित हैं, लेकिन ऐसे सक्रिय विकास के तहत नहीं हैं, तो एक पूर्ण डैशबोर्ड "पुराने" लक्ष्यों पर हावी हो सकता है जो शायद ही कभी बदलते हैं। इस मामले में एक चयनित डैशबोर्ड अधिक उपयुक्त हो सकता है, जहां केवल वे लक्ष्य प्रदर्शित होते हैं जो या तो विफल हो रहे हैं, या हाल ही में सक्रिय हैं। संपूर्ण डैशबोर्ड डेवलपर के डेस्कटॉप के लिए उपलब्ध है, लेकिन वॉल डिस्प्ले केवल महत्वपूर्ण हाइलाइट्स दिखाता है। ऐसे डैशबोर्ड को अक्सर स्थानीय आवश्यकताओं के अनुसार मुख्य डैशबोर्ड को स्क्रीन-स्क्रैप करके और उस पर प्रासंगिक स्थानीय फ़िल्टर लागू करके स्थानीय रूप से कोडित किया जाता है। स्थिर डैशबोर्ड की तुलना में डायनामिक फ़िल्टर्ड डैशबोर्ड का एक दोष यह है कि किसी विशेष लक्ष्य के लिए आइकन की स्थिति स्क्रीन पर बदल सकती है, जिससे पूरे कार्यालय से पढ़ना मुश्किल हो जाता है। इस मामले में, साधारण रंग ब्लॉकों के बजाय विशिष्ट चिह्न, जैसे उत्पाद लोगो, प्रदर्शित किए जा सकते हैं। | ||
==संदर्भ== | ==संदर्भ== | ||
Revision as of 11:18, 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.
