Microsoft Azure DevOps

Съдържание:

• Резюме
  • Проблем
  • Решение
  • Състояние
• Подробности
  • Допускания
  • Ограничения
  • Позиции
  • Аргумент
  • Последици
• Свързани
  • Свързани решения
  • Свързани изисквания
  • Свързани артефакти
  • Свързани принципи
• Бележки
  • Microsoft Devops CI: неудовлетворително приключение
  • Основни моменти от дискусията в Hacker News
  • Windows Development MVP
  • Обобщение от Edward Thomson (Azure PM)

Резюме

Проблем

Искаме да използваме 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, който отговори, че няма да го поправи.

• Документацията често е или грешна, или остаряла. Поне част от това се дължи на лошата търсачка на Microsoft, а част — на посредственото SEO.

• Настройката на Terraform е добре документирана и работи. Поддръжката на Terraform обаче е слаба в сравнение с AWS, защото Microsoft изгражда бизнес отношения с доставчици, за да създават примери за настройка през Terraform в цялата верига.

Опитът на колегите:

• След като направихме собствена слепа оценка, потърсихме опита на колеги. Това, което открихме, потвърди нашия опит.

• Колегите докладваха допълнителни проблеми с времената за изграждане и проблеми със сървъра за изграждане, който си носиш сам (bring-your-own). Тези проблеми са значително по-сериозни от проблемите с UI, защото изграждането е основната цел на конвейера за изграждане и очакваме да правим много изграждания на ден.

• Открихме отлично участие на колеги от Azure в дискусионните области. Поздравления на Microsoft за това. Особено впечатлени сме от Edward Thomson, PM и програмист в Azure, заради участието, прямотата и техническите му обяснения.

Последици

Изборът на Microsoft Azure DevOps изглежда вероятно да бъде по-скъп (~3 пъти) по време и разходи от неизбирането на Azure.

Свързани

Свързани решения

Ако изберем 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 се нарежда на последно място.“

„Потребителският интерфейс е ужасно тромав навсякъде. Най-лошото за мен са 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 за някои персонализирани инструменти

• Новото изживяване с конвейерите просто няма голям смисъл, новите потребители, щракайки наоколо, в крайна сметка ще стигнат до грешната документация.

Обобщение от Edward Thomson (Azure PM)

Аз написах кода, който слива вашите pull request-и. 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/