बिल्ड लाइट इंडिकेटर

From Vigyanwiki
Revision as of 15:04, 25 June 2023 by alpha>Indicwiki (Created page with "{{notability|date=August 2012}} File:Series of build lights.jpg|thumb|वास्तविक निर्माण के अलावा इकाई परीक्ष...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
वास्तविक निर्माण के अलावा इकाई परीक्षण जैसी प्रक्रियाओं पर लागू बिल्ड लाइटों की एक श्रृंखला

बिल्ड लाइट इंडिकेटर एक सरल दृश्य संकेतक है जिसका उपयोग चुस्त सॉफ्टवेयर विकास में सॉफ्टवेयर डेवलपर्स की एक टीम को उनके प्रोजेक्ट की वर्तमान स्थिति के बारे में सूचित करने के लिए किया जाता है। उपयोग की जाने वाली वास्तविक वस्तु दबाव नापने का यंत्र से लेकर लावा लैंप तक भिन्न हो सकती है, लेकिन इसका उद्देश्य एक ही रहता है: जल्दी से सूचित करना कि कोई सॉफ़्टवेयर प्रक्रिया (जैसे कि सॉफ़्टवेयर बिल्ड|'बिल्ड') सफल है या नहीं।

इतिहास

बिल्ड लाइट इंडिकेटर क्रूज नियंत्रण से उत्पन्न हुआ,[citation needed] विचार काम करता है के कर्मचारियों द्वारा बनाया गया एक सतत एकीकरण उपकरण। हालाँकि यह मुख्य रूप से एक वेब पेज डैशबोर्ड के रूप में कार्य करता है जो किसी बिल्ड के बारे में अधिक विस्तृत जानकारी रिपोर्ट कर सकता है, सॉफ्टवेयर सरल रिपोर्टिंग के लिए बाहरी उपकरणों को भी नियंत्रित कर सकता है।[1]


उपयोग

बिल्ड लाइट का पारंपरिक उपयोग निरंतर एकीकरण (सीआई) प्रणाली में सॉफ़्टवेयर निर्माण की सफलता का निर्धारण करना है।[2] विभिन्न विकास टीमों ने अलग-अलग संकेतकों का उपयोग किया है, लेकिन एक लोकप्रिय विकल्प हरा और लाल लावा लैंप है - निर्माण सफल होने पर हरा और कुछ गलत होने पर लाल।[3] बिल्ड लाइट्स को वेबकैम या अन्य माध्यमों से दूर से भी एक्सेस किया जा सकता है।[4] हालाँकि, चूंकि व्यस्त विकास कार्यालयों में कई परीक्षण नवीनतम परिवर्तनों के बाद हमेशा पुन: परीक्षण की स्थिति में रहेंगे, इसलिए कुछ संकेतकों में तीन-राज्य तर्क प्रदर्शन होता है[2]- कर्मचारियों और प्रबंधकों के लिए अधिक सूक्ष्म संकेतक प्रदान करने के लिए उत्तीर्ण, असफल और पुनः परीक्षण किया जाना।[5]


एकल संकेतकों से परे

निरंतर एकीकरण से लेकर निरंतर परीक्षण तक की वृद्धि के साथ, एकल कोडबेस के लिए भी एक साथ निर्माण लक्ष्यों की संख्या बढ़ सकती है। एक सरल निर्माण (यानी संकलन) लक्ष्य के साथ-साथ, अब इकाई परीक्षण और सिस्टम परीक्षण के विभिन्न स्तर होंगे। चूँकि व्यापक परीक्षण धीमे होते हैं और डेवलपर्स को त्वरित प्रतिक्रिया देने के लिए तेज़ चक्र पर तेज़ परीक्षण चलाना वांछनीय है, निर्माण लक्ष्यों की संख्या पचास या अधिक तक बढ़ सकती है। साधारण लावा लैंप डिस्प्ले के साथ दिखाने के लिए यह बहुत अधिक है। जेनकींस (सॉफ्टवेयर) जैसे एकीकरण सर्वर एक वेब-सुलभ डैशबोर्ड पेज प्रदान करते हैं और इसके बजाय इसे दीवार पर लगे फ्लैट स्क्रीन मॉनिटर पर स्थायी रूप से प्रदर्शित किया जा सकता है। ऐसे डैशबोर्ड का विवरण किसी कार्यालय में पढ़ने के लिए बहुत छोटा है, लेकिन रंग परिवर्तन स्थिति की समग्र तस्वीर प्रस्तुत करता है।

निरंतर परीक्षण-संचालित विकास की पद्धति के साथ, नए परीक्षणों को पास करने के लिए कार्यशील कोड विकसित करने से पहले जारी किया जाता है। इस प्रकार एक अवधि होती है जब कुछ परीक्षण ज्ञात होते हैं, और वास्तव में उनका विफल होना आवश्यक होता है।[6] असफल परीक्षणों की आवश्यकता होती है क्योंकि वे चिंता की स्थिति का पता लगाने के लिए नए परीक्षणों की क्षमता को प्रदर्शित करते हैं। एक बार जब नया कोड विकसित हो जाता है और काम करने लगता है, तो ये परीक्षण पास होने लगते हैं। एक निरंतर परीक्षण वातावरण जिसमें नए परीक्षण उनके कोड से पहले जारी किए जाते हैं, इस प्रकार दो निर्माण लक्ष्यों की आवश्यकता होती है: एक नवीनतम कोड और परीक्षणों को ट्रैक करता है, दूसरा 'रिलीज़ उम्मीदवार' केवल वेतन वृद्धि में अपडेट किया जाता है जब सभी परीक्षण कोड पास करके पूरे हो जाते हैं। बिल्ड इंडिकेटर के लिए इसका तात्पर्य यह भी है कि उन लक्ष्यों में से एक को अक्सर उसके परीक्षणों में विफल होने के रूप में दिखाया जाएगा। चूँकि यह प्रत्याशित विफलता भोले-भाले दर्शकों के लिए भ्रामक होगी, निर्माण संकेतक को या तो इसे छिपाना चाहिए या इसे स्पष्ट रूप से प्रस्तुत करना चाहिए।

जहां कई कोड लक्ष्य, जैसे पुराने उत्पाद संस्करण, अभी भी सीआई के लिए समर्थित हैं, लेकिन ऐसे सक्रिय विकास के तहत नहीं हैं, तो एक पूर्ण डैशबोर्ड पुराने लक्ष्यों पर हावी हो सकता है जो शायद ही कभी बदलते हैं। इस मामले में एक चयनित डैशबोर्ड अधिक उपयुक्त हो सकता है, जहां केवल वे लक्ष्य प्रदर्शित होते हैं जो या तो विफल हो रहे हैं, या हाल ही में सक्रिय हैं। संपूर्ण डैशबोर्ड डेवलपर के डेस्कटॉप के लिए उपलब्ध है, लेकिन वॉल डिस्प्ले केवल महत्वपूर्ण हाइलाइट्स दिखाता है। ऐसे डैशबोर्ड को अक्सर स्थानीय आवश्यकताओं के अनुसार मुख्य डैशबोर्ड को स्क्रीन scraping करके और उस पर प्रासंगिक स्थानीय फ़िल्टर लागू करके स्थानीय रूप से कोडित किया जाता है। स्थिर डैशबोर्ड की तुलना में डायनामिक फ़िल्टर्ड डैशबोर्ड का एक दोष यह है कि किसी विशेष लक्ष्य के लिए आइकन की स्थिति स्क्रीन पर बदल सकती है, जिससे पूरे कार्यालय से पढ़ना मुश्किल हो जाता है। इस मामले में, साधारण रंग ब्लॉकों के बजाय विशिष्ट चिह्न, जैसे उत्पाद लोगो, प्रदर्शित किए जा सकते हैं।

संदर्भ

  1. 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. 2.0 2.1 "ओर्ब - संकेतक लैंप बनाएं". agileskunkworks.org. Archived from the original on June 11, 2010.
  3. 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.
  4. 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.
  5. Build Light – Continuous Delivery meets Reengineering an[sic USB driver] Archived September 15, 2013, at the Wayback Machine - Bernd Zuther, comSysto GmbH, 2013
  6. 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.