Architecture Decision Record
← निर्णय नोंद उदाहरणे

Microsoft 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 समर्थन कमकुवत आहे कारण साखळी-माध्यमातून Terraform सेटअप उदाहरणे बनवण्यासाठी Microsoft विक्रेत्यांशी व्यावसायिक संबंध तयार करत आहे.

आमच्या समवयस्कांचे अनुभव:

  • आमचे स्वतःचे अंध मूल्यांकन केल्यानंतर, आम्ही समवयस्कांचे अनुभव शोधले. आम्हाला जे आढळले त्याने आमच्या अनुभवांची पुष्टी केली.

  • समवयस्कांनी बिल्ड वेळांबाबत अतिरिक्त समस्या आणि स्वतःचा बिल्ड सर्व्हर आणण्याबाबतच्या समस्या कळवल्या. या समस्या UI च्या समस्यांपेक्षा लक्षणीयरीत्या अधिक गंभीर आहेत, कारण बिल्ड करणे हा बिल्ड पाइपलाइनचा मुख्य उद्देश आहे, आणि आम्ही दररोज अनेक बिल्ड करण्याची अपेक्षा करतो.

  • आम्हाला चर्चा क्षेत्रांमध्ये Azure सहकाऱ्यांचा उत्कृष्ट सहभाग आढळला. त्यासाठी Microsoft चे कौतुक. Azure PM आणि कोडर Edward Thomson यांच्या सहभागामुळे, सरळपणामुळे आणि तांत्रिक स्पष्टीकरणांमुळे आम्ही विशेषतः प्रभावित झालो.

परिणाम

Microsoft Azure DevOps निवडणे हे Azure न निवडण्यापेक्षा वेळ आणि खर्चात अधिक महाग (~३ पट) ठरण्याची शक्यता दिसते.

संबंधित

संबंधित निर्णय

आम्ही Azure DevOps निवडल्यास, Azure Repo, Azure Pipeline इत्यादींसह अनेक संबंधित ऑफरिंग आहेत. आमचा विश्वास आहे की आम्ही Azure Devops निवडल्यास, यामुळे अधिक Azure क्षमता वापरणे सोपे होऊ शकते, किंवा इतर विक्रेत्यांच्या क्षमता वापरणे कठीण होऊ शकते.

आमचा विश्वास आहे की Microsoft विकासक अनुभवात मोठी प्रगती करत आहे, आणि आम्ही Microsoft ला विकासक साधनांची (उदा. GitHub) आणि अवलंबित्वांची (उदा. Citus) मोठी अधिग्रहणे करताना पाहत आहोत.

आम्ही Azure DevOps निवडल्यास, आम्हाला Microsoft अधिग्रहण ऑफरिंग निवडण्यावर भर द्यायचा असेल, आणि संभाव्य नकार उदा. कर्मचारी गळतीचा धोका यामुळे अधिग्रहण ऑफरिंगकडे अधिक काळजीने/मूल्यांकनाने जायचेही असेल.

संबंधित आवश्यकता

आम्हाला बिल्ड वेळा खूप जलद हव्या आहेत. यासाठी आम्ही मोठा अधिभार भरण्यास तयार आहोत. कारण आम्हाला खूप जलद पुनरावृत्ती करायची आहे.

आम्हाला विश्वासार्हता खूप उच्च हवी आहे. यासाठी आम्ही मोठा अधिभार भरण्यास तयार आहोत. कारण आम्ही आर्थिक व्यवहार, गोपनीय व्यवहार इत्यादींसह उच्च-मूल्याच्या वापर प्रकरणांची चाचणी करत आहोत.

आमच्या शीर्ष ४ 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 सर्वत्र भयंकर अवघडलेले आहे. माझ्यासाठी सर्वात वाईट म्हणजे pull request. pull request वर लोकांसोबत काम करणे अविश्वसनीयरीत्या कठीण आहे. मी तुम्हाला "एका" विशिष्ट समस्येकडेही बोट दाखवू शकत नाही - आमच्यासाठी ते सर्वत्र बिघडलेले आहे."

"Azure Devops असे काहीतरी आहे ज्यावर मला प्रेम करायला आवडेल. UI बदलत राहते, पण वर्षानुवर्षे असलेले मूलभूत बग दुरुस्त करत नाही."

"साधने नीट एकत्रित नाहीत, UI खरोखर संथ आहे, माझ्या आवडत्या रेपोंसाठी सक्रिय pull request, बिल्ड, रिलीझ इत्यादींचे डॅशबोर्ड दृश्य नाही. बिल्ड/डिप्लॉय वेळा भयानक संथ आहेत."

"आम्ही Azure Boards (Work Items, Boards, Backlogs इत्यादी) देखील वापरून पाहिले. अरेरे. तो विसंगत कल्पनांचा संपूर्ण UI गोंधळ आहे. एक गोष्ट नीट अंमलात आणण्याऐवजी, त्यांनी दोन डझन गोष्टी वाईटरीत्या अंमलात आणल्या."

Windows Development MVP

मी Windows Development MVP आहे. या बाबतीत या समस्यांविषयी अधिक मोठ्याने न बोलल्याची काही जबाबदारी मला स्वीकारावी लागेल असे मला वाटते. पण मला म्हणावे लागेल, तुम्हाला UX समस्यांबद्दल "आश्चर्य" वाटते हे ऐकून मी निराश झालो आहे. मी तुमच्या लोकांना सांगत आलो आहे की UX भयंकर आहे (उदा. लाँचच्या आधीपासून) आणि "आम्हाला माहीत आहे, आम्ही दुरुस्त करत आहोत" हे ऐकत राहिलो. मी अभिप्राय औपचारिक स्वरूपात मांडून पाइपलाइनद्वारे पुढे ढकलायला सुरुवात करेन, लक्ष ठेवा. मी स्थानिकही आहे (Bellevue), आणि आमच्या तुलनेने साध्या oss .net/wpf/uwp अॅपचे पाइपलाइनिंग करून पाहण्यासाठी यायला मला आवडेल. मला शंका आहे की ते आपल्या दोघांसाठी डोळे उघडणारे ठरेल.

काही उदाहरणे:

  • सबमॉड्यूल असलेल्या git रेपोसह तुम्ही पाइपलाइन बनवू शकत नाही.

  • काही सानुकूल साधनांसाठी PATH संपादित करणे अशक्य वाटले

  • नवीन पाइपलाइन अनुभवाला फारसा अर्थ नाही, आजूबाजूला क्लिक करणारे नवीन वापरकर्ते अखेरीस चुकीच्या Docs वर पोहोचतात.

Edward Thomson (Azure PM) यांचा सारांश

तुमचे pull request विलीन करणारा कोड मी लिहिला. 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/