Architecture Decision RecordMicrosoft Azure DevOps
विषय-सूची:
सारांश
मुद्दा
हम अपनी परियोजनाओं को बिल्ड, एकीकृत, तैनात और होस्ट करने के लिए devops का उपयोग करना चाहते हैं। हम Microsoft Azure DevOps पर विचार कर रहे हैं।
हम चाहते हैं कि devops की सेटअप, जैसे कॉन्फ़िगर करना, और निरंतर उपयोग, जैसे तेज़ बिल्ड समय, दोनों के लिए डेवलपर अनुभव तेज़ और भरोसेमंद हो।
हम परियोजना के ऐप, डेटाबेस आदि को होस्ट करने के लिए संपूर्ण रूप से Microsoft Azure का उपयोग करने पर विचार करना चाहते हैं।
निर्णय
Microsoft Azure DevOps के विरुद्ध निर्णय लिया।
अवस्था
तय। नई महत्वपूर्ण जानकारी आने पर पुनर्विचार के लिए खुले हैं।
विवरण
मान्यताएँ
सभी सामान्य devops मान्यताएँ, जैसे पुस्तक Accelerate में।
तेज़ बिल्ड से बड़ी मदद मिलती है। इससे प्रतिक्रिया चक्र तेज़ होते हैं।
हम अन्य विक्रेताओं के घटकों को बदलकर लगा/हटा सकते हैं, यानी हम अपने अधिक तेज़ बिल्ड सर्वर लाना चाह सकते हैं, या संस्करण नियंत्रण प्रणाली अपनी पसंद की उपयोग करना चाह सकते हैं, या स्व-होस्टेड निरंतर एकीकरण सर्वर के साथ समन्वय करना चाह सकते हैं।
सुव्यवस्थित उपयोगिता से बड़ी मदद मिलती है, डेवलपर अनुभव के लिए, और बदले में संगति, स्पष्टता, सुरक्षा और सीखने की आसानी जैसे सूक्ष्म क्षेत्रों के लिए।
जब कुछ भी टूटा हुआ या समस्याग्रस्त हो, तो हम समस्या की रिपोर्ट करने का प्रभावी तरीका चाहते हैं। यह किसी भी सुरक्षा-संबंधी समस्या के लिए विशेष रूप से महत्वपूर्ण है।
बाधाएँ
कोई ज्ञात नहीं। Azure ने बाहरी उपकरणों के साथ अच्छी तरह काम करने की सार्वजनिक प्रतिबद्धता जताई है।
रुख
हमने मौजूदा AWS की तुलना में Microsoft Azure Devops के उपयोग पर विचार किया।
हमने Azure DevOps, Azure Pipelines, Azure Repo और Terraform के माध्यम से नया सर्वर चालू करने के Azure के तरीके के साथ प्रयोग किया।
हमने Microsoft प्रतिनिधियों से सहायता प्राप्त करने के साथ प्रयोग किया।
हमने ब्लॉग और Hacker News पर साथियों से जानकारी एकत्र की।
तर्क
Azure DevOps पेशकशों का उत्कृष्ट समूह विज्ञापित करता है, लेकिन वे खरी नहीं उतरतीं, वे एक-दूसरे के साथ अच्छी तरह काम नहीं करतीं, और सहायता खराब है।
हमारा प्रत्यक्ष अनुभव:
Azure सेटअप UI की गड़बड़ी है, जिनमें से कुछ Microsoft खातों से ओवरलैप होते हैं, और कुछ नहीं। जैसे, Azure साइन इन, Microsoft.com साइन इन, Live.com साइन इन आदि हैं और सभी एक साथ चलन में हैं।
हमें सेटअप के दौरान एक मामूली सुरक्षा समस्या मिली, और कोई समाधान नहीं मिला। हमने इसकी रिपोर्ट करने के कई तरीके आज़माए, कई Microsoft प्रतिनिधियों को, बिना सफलता के। हमने इसे Microsoft सुरक्षा को सफलतापूर्वक रिपोर्ट किया, जिसका उत्तर था ठीक नहीं करेंगे (won't fix)।
दस्तावेज़ीकरण प्रायः या तो गलत या पुराना है। इसका कम से कम कुछ हिस्सा Microsoft के खराब सर्च इंजन के कारण है, और कुछ हिस्सा औसत से कम SEO के कारण।
Terraform सेटअप अच्छी तरह दर्ज है, और काम करता है। हालाँकि, AWS की तुलना में Terraform समर्थन कमज़ोर है क्योंकि Microsoft श्रृंखलाबद्ध Terraform सेटअप उदाहरण देने के लिए विक्रेताओं के साथ व्यावसायिक संबंध बना रहा है।
हमारे साथियों के अनुभव:
अपना स्वतंत्र आकलन करने के बाद, हमने साथियों के अनुभव खोजे। जो हमें मिला उसने हमारे अनुभवों की पुष्टि की।
साथियों ने बिल्ड समय की अतिरिक्त समस्याएँ, और अपना बिल्ड सर्वर लाने की समस्याएँ बताईं। ये समस्याएँ UI की समस्याओं से काफ़ी अधिक गंभीर हैं, क्योंकि बिल्ड करना बिल्ड पाइपलाइन का मूल उद्देश्य है, और हम प्रतिदिन कई करने की अपेक्षा रखते हैं।
हमने चर्चा क्षेत्रों में Azure टीम के साथियों की उत्कृष्ट भागीदारी पाई। इसके लिए Microsoft को साधुवाद। हम विशेष रूप से Azure PM और कोडर Edward Thomson से प्रभावित हैं, उनकी भागीदारी, स्पष्टवादिता और तकनीकी व्याख्याओं के कारण।
निहितार्थ
Microsoft Azure DevOps चुनना, Azure न चुनने की तुलना में, समय और लागत में अधिक महँगा (~3 गुना) प्रतीत होता है।
संबंधित
संबंधित निर्णय
यदि हम Azure DevOps चुनते हैं, तो कई संबंधित पेशकशें हैं, जिनमें Azure Repo, Azure Pipeline आदि शामिल हैं। हमारा मानना है कि यदि हम Azure Devops चुनते हैं, तो इससे अधिक Azure क्षमताओं का उपयोग आसान हो सकता है, या अन्य विक्रेताओं की क्षमताओं का उपयोग कठिन हो सकता है।
हमारा मानना है कि Microsoft डेवलपर अनुभव में बड़ी प्रगति कर रहा है, और हम Microsoft को डेवलपर उपकरणों (जैसे GitHub) और निर्भरताओं (जैसे Citus) के बड़े अधिग्रहण करते देख रहे हैं।
यदि हम Azure DevOps चुनते हैं, तो हम Microsoft अधिग्रहण की पेशकशों को चुनने पर ज़ोर देना चाह सकते हैं, और संभावित ऊतक-अस्वीकृति, जैसे कर्मचारी छोड़ने का जोखिम, के कारण अधिग्रहण पेशकशों को अधिक सावधानी/आकलन के साथ देखना भी चाह सकते हैं।
संबंधित आवश्यकताएँ
हम चाहते हैं कि बिल्ड समय बहुत तेज़ हो। हम इसके लिए ऊँचा प्रीमियम देने को स्वीकार करते हैं। इसका कारण यह है कि हम बहुत तेज़ी से पुनरावृत्ति करना चाहते हैं।
हम चाहते हैं कि विश्वसनीयता बहुत ऊँची हो। हम इसके लिए ऊँचा प्रीमियम देने को स्वीकार करते हैं। इसका कारण यह है कि हम उच्च-मूल्य वाले उपयोग-मामलों का परीक्षण कर रहे हैं, जिनमें वित्तीय लेन-देन, गोपनीय लेन-देन आदि शामिल हैं।
हमारे शीर्ष 4 devops KPI में औसत पुनर्प्राप्ति समय शामिल है, जिसके लिए तेज़ बिल्ड और उच्च विश्वसनीयता आवश्यक है।
संबंधित कलाकृतियाँ
हम चाहते हैं कि बिल्ड प्रणाली ऐसी कलाकृतियाँ आउटपुट करे जो Artifactory जैसी अन्य प्रणालियों में उपयोग के लिए उपयुक्त हों।
संबंधित सिद्धांत
आसानी से पलटा जा सकने वाला। हम Azure DevOps का मूल्यांकन मौजूदा AWS के साथ समानांतर रूप से कर सकते हैं।
टिप्पणियाँ
Microsoft Devops CI: एक असंतोषजनक साहसिक यात्रा
https://toxicbakery.github.io/vsts-devops/microsoft-devops-ci/
ब्लॉग पोस्ट।
"एक सॉफ़्टवेयर डेवलपर के रूप में, मैं प्रत्यक्ष अनुभव से जानता हूँ कि गुणवत्तापूर्ण उत्पाद तेज़ी से और सस्ते में बनाना कितना कठिन है। यह एक कला है जिसे हम कभी-कभी सही कर पाते हैं, और अन्य समय यह ओबामा-युग की स्वास्थ्य सेवा सरकारी साइट जैसी किसी चीज़ में बदल जाती है। परिणामी उत्पाद पर हमारे नियंत्रण का स्तर अलग-अलग होता है, और विफलता का दोष प्रायः निर्णय-पदानुक्रम में गलत लोगों पर पड़ता है। Microsoft का Azure DevOps (पहले Visual Studio Team Services), स्पष्ट रूप से अच्छे इरादों के बावजूद, खराब निर्णयों और कमज़ोर क्रियान्वयन का एकदम सही तूफ़ान है।"
Hacker News चर्चा के मुख्य अंश
https://news.ycombinator.com/item?id=18983586
"हम अपने काम में Azure DevOps का व्यापक उपयोग करते हैं और, GitHub, Gitlab, स्व-होस्टेड समाधान, Jenkins, TeamCity का उपयोग करने के बाद... Azure DevOps सबसे आखिरी स्थान पर है।"
"UI हर जगह बेहद अटपटा है। मेरे लिए सबसे खराब पुल रिक्वेस्ट हैं। पुल रिक्वेस्ट पर लोगों के साथ काम करना अविश्वसनीय रूप से कठिन है। मैं किसी "एक" विशेष समस्या की ओर इशारा भी नहीं कर सकता - हमारे लिए यह हर जगह टूटा हुआ है।"
"Azure Devops ऐसा है जिसे मैं पसंद करना चाहता हूँ। UI बदलता रहता है, लेकिन लंबे समय से मौजूद अंतर्निहित बग ठीक नहीं करता।"
"उपकरण अच्छी तरह एकीकृत नहीं हैं, UI वास्तव में धीमा है, मेरे पसंदीदा रिपॉज़िटरी के सक्रिय पुल रिक्वेस्ट, बिल्ड, रिलीज़ आदि का कोई डैशबोर्ड दृश्य नहीं है। बिल्ड/डिप्लॉय समय बेतहाशा धीमा है।"
"हमने Azure Boards (वर्क आइटम, बोर्ड, बैकलॉग आदि) का उपयोग करने की भी कोशिश की। उफ़। यह बेमेल विचारों का पूरी तरह उलझा हुआ UI है। एक चीज़ को अच्छी तरह लागू करने के बजाय, उन्होंने दो दर्जन चीज़ें खराब तरीके से लागू कीं।"
Windows Development MVP
मैं यहाँ Windows Development MVP हूँ। मुझे लगता है कि इन समस्याओं के बारे में अधिक मुखर न होने की कुछ ज़िम्मेदारी मुझे उठानी चाहिए। लेकिन कहना होगा, यह सुनकर निराशा हुई कि आप UX समस्याओं से "आश्चर्यचकित" हैं। मैं आपके लोगों को बताता रहा हूँ कि UX भयावह है (जैसे लॉन्च से पहले के समय से ही) और जवाब में सुनता रहा "हम जानते हैं, हम ठीक कर रहे हैं"। मैं प्रतिक्रिया को औपचारिक रूप देना शुरू करूँगा और उसे चैनलों के माध्यम से आगे बढ़ाऊँगा, बने रहिए। मैं स्थानीय (Bellevue) भी हूँ, आना और अपने अपेक्षाकृत सरल ओपन-सोर्स .net/wpf/uwp ऐप को पाइपलाइन में डालने की कोशिश करना पसंद करूँगा। मुझे संदेह है कि यह हम दोनों के लिए आँखें खोलने वाला होगा।
कुछ उदाहरण:
आप ऐसे git रिपॉज़िटरी के साथ पाइपलाइन नहीं बना सकते जिसमें सबमॉड्यूल हों
कुछ कस्टम टूलिंग के लिए PATH संपादित करना असंभव पाया
New Pipeline अनुभव का कोई ख़ास मतलब नहीं बनता, नए उपयोगकर्ता इधर-उधर क्लिक करते-करते अंततः गलत दस्तावेज़ों तक पहुँच जाते हैं।
Edward Thomson (Azure PM) का सारांश
मैंने वह कोड लिखा जो आपके पुल रिक्वेस्ट को मर्ज करता है। Azure DevOps के लिए Microsoft में प्रोग्राम मैनेजर; पहले GitHub, Microsoft, SourceGear में संस्करण नियंत्रण उपकरणों पर सॉफ़्टवेयर इंजीनियर।
https://www.edwardthomson.com/
libgit2 के सह-अनुरक्षक। https://libgit2.github.io
All Things Git, Git के बारे में पॉडकास्ट, के सह-मेज़बान। https://www.allthingsgit.com/
Developer Tools Weekly, डेवलपमेंट उपकरणों के बारे में न्यूज़लेटर, के क्यूरेटर। https://developertoolsweekly.com/