Microsoft Azure DevOps

المحتويات:

• الملخص
  • المسألة
  • القرار
  • الحالة
• التفاصيل
  • الافتراضات
  • القيود
  • المواقف
  • الحجة
  • التبعات
• ذو صلة
  • قرارات ذات صلة
  • متطلبات ذات صلة
  • نواتج ذات صلة
  • مبادئ ذات صلة
• ملاحظات
  • Microsoft Devops CI: مغامرة غير مرضية
  • أبرز نقاط النقاش في Hacker News
  • خبير Windows Development MVP
  • ملخص Edward Thomson (مدير منتج Azure)

الملخص

المسألة

نريد استخدام devops لبناء مشاريعنا ودمجها ونشرها واستضافتها. وننظر في Microsoft Azure DevOps.

• نريد أن تكون تجربة المطور سريعة وموثوقة، سواء في إعداد devops مثل التهيئة، أو في الاستخدام المستمر مثل سرعة أزمنة البناء.

• نريد النظر في استخدام Microsoft Azure ككل، لاستضافة تطبيقات المشروع وقواعد بياناته وغيرها.

القرار

تقرر عدم اعتماد Microsoft Azure DevOps.

الحالة

تم القرار. ونحن منفتحون على إعادة النظر إذا/عندما تصل معلومات جديدة مهمة.

التفاصيل

الافتراضات

كل افتراضات devops المعتادة، مثل تلك الواردة في كتاب Accelerate.

• أزمنة البناء السريعة مساعد كبير. فهي تسرّع حلقات التغذية الراجعة.

• نستطيع تبديل مكونات من موردين بديلين إدخالًا وإخراجًا، أي قد نرغب في جلب خوادم بناء أعلى سرعة خاصة بنا، أو استخدام نظام التحكم في الإصدارات الذي نختاره، أو التنسيق مع خادم تكامل مستمر مستضاف ذاتيًا.

• سهولة الاستخدام المبسّطة مساعد كبير، لتجربة المطور، وبالتالي لجوانب دقيقة مثل الاتساق والوضوح والأمان وسهولة منحنى التعلم.

• عندما يكون أي شيء معطلًا أو مشكلًا، نريد وسيلة فعالة للإبلاغ عن المشكلة. وهذا مهم خصوصًا لأي مشكلات متعلقة بالأمان.

القيود

لا قيود معروفة. فلدى Azure التزام معلن بالتوافق الجيد مع الأدوات الخارجية.

المواقف

نظرنا في استخدام Microsoft Azure Devops مقابل AWS المعتمدة حاليًا.

وجرّبنا Azure DevOps وAzure Pipelines وAzure Repo وتشغيل خادم جديد في Azure عبر Terraform.

وجرّبنا الحصول على دعم من ممثلي Microsoft.

وجمعنا معلومات من الأقران في المدونات وفي Hacker News.

الحجة

يعلن Azure DevOps عن مجموعة ممتازة من العروض، لكنها لا تصمد، ولا تعمل جيدًا معًا، والدعم ضعيف.

تجربتنا المباشرة:

• إعداد Azure فوضى من واجهات المستخدم، بعضها يتداخل مع حسابات Microsoft وبعضها لا. فمثلًا، هناك تسجيل دخول Azure، وتسجيل دخول Microsoft.com، وتسجيل دخول Live.com، وغيرها، وكلها قيد العمل في وقت واحد.

• واجهنا مشكلة أمنية بسيطة أثناء الإعداد، ولم نجد لها حلًّا. جرّبنا طرقًا كثيرة للإبلاغ عنها، إلى ممثلي Microsoft كثيرين، دون نجاح. وأبلغنا عنها بنجاح فريق أمان Microsoft، الذي ردّ بأنها لن تُصلَح (won't fix).

• التوثيق إما خاطئ وإما قديم في أغلب الأحيان. ويرجع بعض ذلك على الأقل إلى ضعف محرك بحث Microsoft، وبعضه إلى تحسين محركات البحث (SEO) الرديء.

• إعداد Terraform موثق جيدًا ويعمل. غير أن دعم Terraform ضعيف مقارنةً بـAWS لأن Microsoft تبني علاقات تجارية مع الموردين لتقديم أمثلة إعداد Terraform متسلسلة.

تجارب أقراننا:

• بعد إجراء تقييمنا المستقل، بحثنا عن تجارب الأقران. وما وجدناه أكّد تجاربنا.

• أبلغ الأقران عن مشكلات إضافية في أزمنة البناء، ومشكلات في استخدام خادم البناء الخاص. وهذه المشكلات أشد خطورة بكثير من مشكلات واجهة المستخدم، لأن تنفيذ عمليات البناء هو الغرض الأساسي من خط البناء، ونتوقع إجراء الكثير منها يوميًا.

• وجدنا مشاركة ممتازة من زملاء Azure في ساحات النقاش. التحية لـMicrosoft على ذلك. وقد أعجبنا بوجه خاص Edward Thomson، مدير المنتج والمبرمج في Azure، لمشاركته وصراحته وشروحه التقنية.

التبعات

يبدو أن اختيار Microsoft Azure DevOps سيكون على الأرجح أغلى (نحو 3 أضعاف) في الوقت والتكلفة من عدم اختيار Azure.

ذو صلة

قرارات ذات صلة

إذا اخترنا Azure DevOps، فهناك عروض كثيرة ذات صلة، منها Azure Repo وAzure Pipeline وغيرهما. ونعتقد أنه إذا اخترنا Azure Devops، فقد يسهّل ذلك استخدام مزيد من قدرات Azure، أو قد يصعّب استخدام قدرات موردين آخرين.

ونعتقد أن Microsoft تحقق خطوات كبيرة في تجربة المطور، ونرى Microsoft تجري عمليات استحواذ كبيرة على أدوات المطورين (مثل GitHub) والاعتماديات (مثل Citus).

وإذا اخترنا Azure DevOps، فقد نرغب في التركيز على اختيار العروض المستحوذ عليها من Microsoft، وقد نرغب أيضًا في التعامل مع العروض المستحوذ عليها بمزيد من الحرص/التقييم بسبب احتمال رفض الأنسجة، مثل خطر دوران الموظفين.

متطلبات ذات صلة

نريد أزمنة بناء سريعة جدًا. ونقبل دفع علاوة مرتفعة مقابل ذلك. وذلك لأننا نريد التكرار بسرعة كبيرة.

نريد موثوقية عالية جدًا. ونقبل دفع علاوة مرتفعة مقابل ذلك. وذلك لأننا نختبر حالات استخدام عالية القيمة، منها معاملات مالية ومعاملات سرية وغيرها.

تتضمن أهم 4 مؤشرات أداء رئيسية في devops لدينا متوسط زمن التعافي، الذي يستلزم عمليات بناء سريعة وموثوقية عالية.

نواتج ذات صلة

نريد أن ينتج نظام البناء نواتج تصلح للاستخدام في أنظمة أخرى، مثل Artifactory.

مبادئ ذات صلة

سهل التراجع عنه. نستطيع تقييم Azure DevOps بالتوازي مع AWS المعتمدة حاليًا.

ملاحظات

Microsoft Devops CI: مغامرة غير مرضية

https://toxicbakery.github.io/vsts-devops/microsoft-devops-ci/

تدوينة.

«بصفتي مطور برمجيات، أعلم من تجربة مباشرة مدى صعوبة بناء منتجات عالية الجودة بسرعة وبتكلفة منخفضة. إنه فن ننجح فيه أحيانًا، وفي أحيان أخرى يتحول إلى شيء يشبه موقع الرعاية الصحية الحكومي في عهد أوباما. يتفاوت مستوى تحكمنا في المنتج الناتج، وكثيرًا ما يقع اللوم على الأشخاص الخطأ في التسلسل الهرمي لاتخاذ القرار. إن Azure DevOps من Microsoft (المعروف سابقًا باسم Visual Studio Team Services)، رغم النوايا الحسنة الواضحة، عاصفة مثالية من القرارات السيئة والتنفيذ الضعيف».

أبرز نقاط النقاش في Hacker News

https://news.ycombinator.com/item?id=18983586

«نستخدم Azure DevOps بكثافة في عملي، وبعد استخدام GitHub وGitlab والحلول المستضافة ذاتيًا وJenkins وTeamCity... يأتي Azure DevOps في المرتبة الأخيرة تمامًا».

«واجهة المستخدم متثاقلة بشكل فظيع في كل مكان. الأسوأ بالنسبة إليّ هو طلبات الدمج (pull requests). من الصعب جدًا العمل مع الناس على طلب دمج. لا أستطيع حتى الإشارة إلى مشكلة "واحدة" بعينها - فهو معطل لدينا في كل مكان».

«Azure Devops شيء أتمنى أن أحبه. تتغير الواجهة باستمرار، لكنها لا تصلح الأخطاء الجوهرية الموجودة منذ زمن طويل».

«الأدوات غير متكاملة جيدًا، وواجهة المستخدم بطيئة حقًا، ولا يوجد عرض لوحة معلومات لطلبات الدمج النشطة وعمليات البناء والإصدارات وغيرها لمستودعاتي المفضلة. أزمنة البناء/النشر بطيئة بشكل جنوني».

«حاولنا أيضًا استخدام Azure Boards (عناصر العمل واللوحات وقوائم المهام المتراكمة وغيرها). يا للهول. إنها فوضى كاملة في واجهة المستخدم من أفكار متنافرة. بدلًا من تنفيذ شيء واحد بإتقان، نفّذوا عشرات الأشياء بشكل سيئ».

خبير Windows Development MVP

أنا خبير MVP في تطوير Windows. أشعر أنه يجب أن أتحمل جزءًا من المسؤولية لأنني لم أكن أعلى صوتًا بشأن هذه المشكلات. لكن يجب أن أقول إنني خاب أملي لسماع أنكم «متفاجئون» من مشكلات تجربة المستخدم. فقد كنت أقول لفريقكم إن تجربة المستخدم فظيعة (مثلًا منذ ما قبل الإطلاق) وكنت أسمع الرد «نعلم، ونحن نصلحها». سأبدأ بتحويل الملاحظات إلى صيغة رسمية وتمريرها عبر القنوات، فابقوا على اطلاع. وأنا محلي أيضًا (Bellevue)، وسأحب أن آتي وأحاول تمرير تطبيقنا المفتوح المصدر البسيط نسبيًا .net/wpf/uwp عبر خط. أظن أن ذلك سيفتح أعيننا نحن الاثنين.

بعض الأمثلة:

• لا يمكنك بناء خط مع مستودع git يحتوي على وحدات فرعية (submodules)

• وجدت أنه يستحيل تعديل PATH لبعض الأدوات المخصصة

• تجربة New Pipeline لا معنى لها كثيرًا، والمستخدمون الجدد الذين ينقرون هنا وهناك سينتهون في النهاية إلى التوثيق الخطأ.

ملخص Edward Thomson (مدير منتج Azure)

أنا كتبت الشيفرة التي تدمج طلبات الدمج لديكم. مدير برامج (Program Manager) في Microsoft لـ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/