Microsoft Azure DevOps

فهرست مطالب:

• خلاصه
  • مسئله
  • تصمیم
  • وضعیت
• جزئیات
  • مفروضات
  • قیود
  • مواضع
  • استدلال
  • پیامدها
• مرتبط
  • تصمیمات مرتبط
  • الزامات مرتبط
  • مصنوعات مرتبط
  • اصول مرتبط
• توضیحات
  • Microsoft Devops CI: An Unsatisfying Adventure
  • Hacker News discussion highlights
  • Windows Development MVP
  • Edward Thomson (Azure PM) summary

خلاصه

مسئله

می‌خواهیم از 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 مجموعه‌ای درهم از UIهاست که برخی با حساب‌های Microsoft همپوشانی دارند و برخی ندارند. مثلاً ورود Azure، ورود Microsoft.com، ورود Live.com و غیره وجود دارد و همه همزمان در کارند.

• در حین راه‌اندازی به یک مسئلهٔ امنیتی جزئی برخوردیم و راه‌حلی نیافتیم. راه‌های بسیاری را برای گزارش آن به نمایندگان متعدد Microsoft امتحان کردیم، بدون موفقیت. با موفقیت آن را به امنیت Microsoft گزارش کردیم که پاسخ داد رفع نخواهد شد (won't fix).

• مستندات اغلب یا اشتباه‌اند یا منسوخ. دست‌کم بخشی از این به دلیل موتور جست‌وجوی ضعیف Microsoft است و بخشی به دلیل SEO پایین‌تر از متوسط.

• راه‌اندازی Terraform به‌خوبی مستند است و کار می‌کند. با این حال، پشتیبانی از Terraform در مقایسه با AWS ضعیف است زیرا Microsoft در حال ایجاد روابط تجاری با تأمین‌کنندگان برای ارائهٔ نمونه‌های راه‌اندازی Terraform زنجیره‌ای است.

تجربه‌های همتایان ما:

• پس از ارزیابی کور خودمان، به دنبال تجربه‌های همتایان گشتیم. آنچه یافتیم تجربه‌های ما را تأیید کرد.

• همتایان مشکلات اضافی با زمان‌های ساخت و مشکلاتی با آوردن سرور ساخت خودی گزارش کردند. این مشکلات به‌طور چشمگیری از مشکلات UI جدی‌ترند، زیرا انجام ساخت هدف اصلی یک خط‌لولهٔ ساخت است و انتظار داریم روزانه ساخت‌های بسیاری انجام دهیم.

• مشارکت عالی هم‌تیمی‌های 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 تأکید کنیم، و همچنین ممکن است بخواهیم به دلیل رد بافت بالقوه، مثلاً ریسک ترک کارکنان، با دقت/ارزیابی بیشتری به پیشنهادهای تملک‌شده بپردازیم.

الزامات مرتبط

می‌خواهیم زمان‌های ساخت بسیار سریع باشند. پرداخت حق‌بیمهٔ بالا برای این را می‌پذیریم. این به این دلیل است که می‌خواهیم بسیار سریع تکرار کنیم.

می‌خواهیم قابلیت اطمینان بسیار بالا باشد. پرداخت حق‌بیمهٔ بالا برای این را می‌پذیریم. این به این دلیل است که موارد استفاده با ارزش بالا، از جمله تراکنش‌های مالی، تراکنش‌های محرمانه و غیره را آزمایش می‌کنیم.

چهار KPI برتر devops ما شامل میانگین زمان بازیابی است که ساخت‌های سریع و قابلیت اطمینان بالا را ضروری می‌کند.

مصنوعات مرتبط

می‌خواهیم سیستم ساخت مصنوعاتی خروجی دهد که برای استفاده در سیستم‌های دیگر، مانند Artifactory، مناسب باشند.

اصول مرتبط

به‌آسانی برگشت‌پذیر. می‌توانیم Azure DevOps را به موازات AWS فعلی ارزیابی کنیم.

توضیحات

Microsoft Devops CI: An Unsatisfying Adventure

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

پست وبلاگ.

«به‌عنوان یک توسعه‌دهندهٔ نرم‌افزار، از تجربهٔ مستقیم می‌دانم ساخت محصولات باکیفیت به‌سرعت و ارزان چقدر دشوار است. این هنری است که گاهی درست از آب درمی‌آوریم و گاهی به چیزی شبیه وب‌سایت دولتی بیمهٔ درمانی دوران Obama تبدیل می‌شود. میزان کنترل ما بر محصول نهایی متفاوت است و سرزنش شکست اغلب بر دوش افراد نادرست در سلسله‌مراتب تصمیم‌گیری می‌افتد. Azure DevOps از Microsoft (که پیش‌تر Visual Studio Team Services نامیده می‌شد)، با وجود نیت‌های آشکارا خوب، توفان کاملی از تصمیم‌های بد و اجرای ضعیف است.»

Hacker News discussion highlights

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 که شامل submoduleهاست بسازید

• ویرایش PATH برای برخی ابزارهای سفارشی غیرممکن بود

• تجربهٔ New Pipeline چندان منطقی نیست، کاربران جدید که این‌طرف و آن‌طرف کلیک می‌کنند در نهایت به مستندات اشتباه می‌رسند.

Edward Thomson (Azure PM) summary

من کدی را نوشتم که pull requestهای شما را ادغام می‌کند. مدیر برنامه در 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/