Architecture Decision Recordمائیکروسافٹ Azure DevOps
فہرست:
خلاصہ
مسئلہ
ہم اپنے منصوبوں کو بلڈ، ضم، ڈپلائے اور ہوسٹ کرنے کے لیے devops استعمال کرنا چاہتے ہیں۔ ہم مائیکروسافٹ Azure DevOps پر غور کر رہے ہیں۔
ہم چاہتے ہیں کہ ڈویلپر کا تجربہ تیز اور قابلِ اعتماد ہو، devops کے سیٹ اپ، مثلاً کنفیگر کرنے، اور جاری استعمال، مثلاً تیز بلڈ اوقات، دونوں کے لیے۔
ہم منصوبے کی ایپس، ڈیٹا بیسز وغیرہ کی ہوسٹنگ کے لیے مجموعی طور پر مائیکروسافٹ Azure استعمال کرنے پر غور کرنا چاہتے ہیں۔
فیصلہ
مائیکروسافٹ Azure DevOps کے خلاف فیصلہ کیا گیا۔
حالت
فیصلہ ہو گیا۔ نئی اہم معلومات آنے پر نظرثانی کے لیے کھلے ہیں۔
تفصیلات
مفروضات
تمام معمول کے devops مفروضات، جیسے کتاب Accelerate میں۔
تیز بلڈز نمایاں مدد ہیں۔ یہ رائے کے چکروں کو تیز کرتے ہیں۔
ہم متبادل وینڈرز کے حصے اندر باہر کر سکتے ہیں، یعنی ہم اپنے تیز رفتار بلڈ سرورز لانا چاہ سکتے ہیں، یا اپنی پسند کا ورژن کنٹرول سسٹم استعمال کرنا چاہ سکتے ہیں، یا خود ہوسٹ کردہ مسلسل انضمام کے سرور کے ساتھ ہم آہنگ ہونا چاہ سکتے ہیں۔
سلیقے سے ترتیب دی گئی قابلِ استعمالیت نمایاں مدد ہے، ڈویلپر کے تجربے کے لیے، اور بدلے میں مطابقت، وضاحت، سیکیورٹی اور سیکھنے کے خم کی آسانی جیسے باریک شعبوں کے لیے۔
جب کچھ ٹوٹا ہوا یا مسئلہ زدہ ہو تو ہم مسئلے کی اطلاع دینے کا مؤثر طریقہ چاہتے ہیں۔ یہ سیکیورٹی سے متعلق کسی بھی مسئلے کے لیے خاص طور پر اہم ہے۔
پابندیاں
کوئی معلوم نہیں۔ Azure کا بیرونی ٹولز کے ساتھ اچھی طرح چلنے کا شائع شدہ عہد ہے۔
مؤقف
ہم نے موجودہ AWS کے مقابلے میں مائیکروسافٹ Azure Devops استعمال کرنے پر غور کیا۔
ہم نے Azure DevOps، Azure Pipelines، Azure Repo اور Terraform کے ذریعے Azure میں نیا سرور چالو کرنے کے تجربات کیے۔
ہم نے مائیکروسافٹ نمائندوں سے سپورٹ لینے کے تجربات کیے۔
ہم نے بلاگز اور Hacker News پر ساتھیوں سے معلومات جمع کیں۔
دلیل
Azure DevOps پیشکشوں کے بہترین مجموعے کا اشتہار دیتا ہے، لیکن وہ ٹھہرتی نہیں، اور اکٹھے اچھی طرح کام نہیں کرتیں، اور سپورٹ کمزور ہے۔
ہمارا براہِ راست تجربہ:
Azure کا سیٹ اپ UIs کی گڑبڑ ہے، جن میں سے کچھ مائیکروسافٹ اکاؤنٹس کے ساتھ ملتے ہیں اور کچھ نہیں۔ مثلاً ایک Azure سائن اِن، ایک Microsoft.com سائن اِن، ایک Live.com سائن اِن وغیرہ ہے اور سب بیک وقت زیرِ استعمال ہیں۔
ہمیں سیٹ اپ کے دوران ایک معمولی سیکیورٹی مسئلہ پیش آیا، اور کوئی حل نہ ملا۔ ہم نے بہت سے مائیکروسافٹ نمائندوں کو اس کی اطلاع دینے کے کئی طریقے آزمائے، کامیابی نہیں ملی۔ ہم نے کامیابی سے مائیکروسافٹ سیکیورٹی کو اطلاع دی، جس نے جواب دیا کہ اسے ٹھیک نہیں کیا جائے گا (won't fix)۔
دستاویزات اکثر یا تو غلط ہوتی ہیں یا پرانی۔ اس کا کم از کم کچھ حصہ مائیکروسافٹ کے کمزور سرچ انجن کی وجہ سے ہے، اور کچھ حصہ کم تر SEO کی وجہ سے۔
Terraform سیٹ اپ اچھی طرح دستاویزی ہے اور کام کرتا ہے۔ تاہم AWS کے مقابلے میں Terraform سپورٹ کمزور ہے کیونکہ مائیکروسافٹ سلسلہ وار Terraform سیٹ اپ کی مثالیں بنانے کے لیے وینڈرز کے ساتھ کاروباری تعلقات قائم کر رہا ہے۔
ہمارے ساتھیوں کے تجربات:
اپنا آزاد جائزہ لینے کے بعد ہم نے ساتھیوں کے تجربات تلاش کیے۔ جو ہمیں ملا اس نے ہمارے تجربات کی تصدیق کی۔
ساتھیوں نے بلڈ اوقات کے اضافی مسائل اور اپنا بلڈ سرور لانے کے مسائل کی اطلاع دی۔ یہ مسائل UI کے مسائل سے نمایاں طور پر زیادہ سنگین ہیں، کیونکہ بلڈ کرنا بلڈ پائپ لائن کا بنیادی مقصد ہے، اور ہم روزانہ بہت سے بلڈز کی توقع کرتے ہیں۔
ہم نے بحث کے مقامات میں Azure ساتھیوں کی بہترین شرکت پائی۔ اس کے لیے مائیکروسافٹ کو شاباش۔ ہم خاص طور پر Azure PM اور کوڈر Edward Thomson کی شرکت، صاف گوئی اور تکنیکی وضاحتوں سے متاثر ہیں۔
مضمرات
مائیکروسافٹ Azure DevOps کا انتخاب Azure کا انتخاب نہ کرنے کے مقابلے میں وقت اور لاگت میں غالباً زیادہ مہنگا (~3 گنا) معلوم ہوتا ہے۔
متعلقہ
متعلقہ فیصلے
اگر ہم Azure DevOps چنتے ہیں تو بہت سی متعلقہ پیشکشیں ہیں، بشمول Azure Repo، Azure Pipeline وغیرہ۔ ہمارا ماننا ہے کہ اگر ہم Azure Devops چنتے ہیں تو اس سے Azure کی مزید صلاحیتیں استعمال کرنا آسان ہو سکتا ہے، یا دوسرے وینڈرز کی صلاحیتیں استعمال کرنا مشکل ہو سکتا ہے۔
ہمارا ماننا ہے کہ مائیکروسافٹ ڈویلپر کے تجربے میں بڑی پیش رفت کر رہا ہے، اور ہم مائیکروسافٹ کو ڈویلپر ٹولز (مثلاً GitHub) اور انحصارات (مثلاً Citus) کی بڑی خریداریاں کرتے دیکھ رہے ہیں۔
اگر ہم Azure DevOps چنتے ہیں تو ہم مائیکروسافٹ کی خریدی ہوئی پیشکشیں چننے پر زور دینا چاہ سکتے ہیں، اور ممکنہ ٹشو ریجیکشن، مثلاً عملے کے چھوڑ جانے کے خطرے کی وجہ سے خریدی ہوئی پیشکشوں کے ساتھ زیادہ احتیاط/جائزے سے پیش آنا بھی چاہ سکتے ہیں۔
متعلقہ تقاضے
ہم بلڈ اوقات بہت تیز چاہتے ہیں۔ ہم اس کے لیے بھاری اضافی قیمت دینا قبول کرتے ہیں۔ یہ اس لیے کہ ہم بہت تیزی سے تکرار کرنا چاہتے ہیں۔
ہم قابلِ اعتمادی بہت بلند چاہتے ہیں۔ ہم اس کے لیے بھاری اضافی قیمت دینا قبول کرتے ہیں۔ یہ اس لیے کہ ہم مالیاتی ٹرانزیکشنز، رازدارانہ ٹرانزیکشنز وغیرہ سمیت اعلیٰ قدر کے استعمال کے کیسز کی جانچ کر رہے ہیں۔
ہمارے سرِفہرست 4 devops KPIs میں بحالی کا اوسط وقت شامل ہے، جس کے لیے تیز بلڈز اور اعلیٰ قابلِ اعتمادی ضروری ہیں۔
متعلقہ آرٹیفیکٹس
ہم چاہتے ہیں کہ بلڈ سسٹم ایسے آرٹیفیکٹس آؤٹ پٹ کرے جو دوسرے سسٹمز، جیسے Artifactory، میں استعمال کے لیے موزوں ہوں۔
متعلقہ اصول
آسانی سے واپس لیا جا سکتا ہے۔ ہم Azure DevOps کا جائزہ موجودہ AWS کے متوازی لے سکتے ہیں۔
نوٹس
Microsoft Devops CI: ایک غیر تسلی بخش مہم جوئی
https://toxicbakery.github.io/vsts-devops/microsoft-devops-ci/
بلاگ پوسٹ۔
“بطور سافٹ ویئر ڈویلپر، میں ذاتی تجربے سے جانتا ہوں کہ معیاری مصنوعات کو تیزی اور سستے میں بنانا کتنا مشکل ہے۔ یہ ایک فن ہے جو ہم کبھی کبھی درست کر لیتے ہیں، اور دوسرے اوقات اوباما دور کی صحت کی سرکاری سائٹ جیسی کسی چیز میں بدل جاتا ہے۔ نتیجے میں بننے والی مصنوعات پر ہمارے کنٹرول کی سطح مختلف ہوتی ہے، اور ناکامی کا الزام اکثر فیصلہ سازی کے درجہ بندی میں غلط لوگوں پر آتا ہے۔ مائیکروسافٹ کا 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 (Work Items, Boards, Backlogs وغیرہ) بھی استعمال کرنے کی کوشش کی۔ اف۔ یہ بے ربط خیالات کی مکمل UI گڑبڑ ہے۔ ایک چیز اچھی طرح نافذ کرنے کی بجائے، انہوں نے دو درجن چیزیں بری طرح نافذ کیں۔”
Windows Development MVP
Windows Development MVP یہاں۔ مجھے لگتا ہے کہ ان مسائل پر زیادہ بلند آواز نہ ہونے کی کچھ ذمہ داری مجھے بھی اٹھانی چاہیے۔ لیکن کہنا ہوگا کہ مجھے یہ سن کر مایوسی ہوئی کہ آپ UX کے مسائل پر “حیران” ہیں۔ میں آپ کے لوگوں کو بتاتا رہا ہوں کہ UX خوفناک ہے (مثلاً لانچ سے بھی پہلے سے) اور جواب سنتا رہا “ہم جانتے ہیں، ہم ٹھیک کر رہے ہیں۔” میں رائے کو باضابطہ بنانا اور اسے نالیوں کے ذریعے آگے بڑھانا شروع کروں گا، دیکھتے رہیں۔ میں مقامی بھی ہوں (Bellevue)، اور آ کر اپنی نسبتاً سادہ اوپن سورس .net/wpf/uwp ایپ کو پائپ لائن سے گزارنے کی کوشش کرنا پسند کروں گا۔ مجھے شبہ ہے کہ یہ ہم دونوں کی آنکھیں کھول دے گا۔
کچھ مثالیں:
آپ ایسی git ریپو کے ساتھ پائپ لائن نہیں بنا سکتے جس میں ذیلی ماڈیولز (submodules) ہوں
کچھ حسبِ ضرورت ٹولنگ کے لیے PATH میں ترمیم ناممکن پائی
New Pipeline کا تجربہ زیادہ معنی نہیں رکھتا، نئے صارفین ادھر ادھر کلک کرتے آخر کار غلط دستاویزات پر پہنچیں گے۔
Edward Thomson (Azure PM) کا خلاصہ
میں نے وہ کوڈ لکھا جو آپ کی پل ریکوئسٹس کو ضم کرتا ہے۔ مائیکروسافٹ میں Azure DevOps کا پروگرام مینیجر؛ پہلے 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/