Microsoft Azure DevOps

Зміст:

• Підсумок
  • Проблема
  • Рішення
  • Статус
• Подробиці
  • Припущення
  • Обмеження
  • Позиції
  • Аргумент
  • Наслідки
• Пов’язане
  • Пов’язані рішення
  • Пов’язані вимоги
  • Пов’язані артефакти
  • Пов’язані принципи
• Примітки
  • Microsoft Devops CI: пригода, що розчаровує
  • Підбірка з обговорення на Hacker News
  • MVP з розробки для Windows
  • Підсумок Edward Thomson (PM 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, яка відповіла «виправляти не будемо».

• Документація часто або хибна, або застаріла. Принаймні частково це пов’язано з поганою пошуковою системою Microsoft, а частково — з посереднім SEO.

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

Досвід наших колег:

• Після нашої власної сліпої оцінки ми шукали досвід колег. Те, що ми знайшли, підтвердило наш досвід.

• Колеги повідомляли про додаткові проблеми з часом збірки та проблеми з використанням власного сервера збірки. Ці проблеми значно серйозніші за проблеми інтерфейсу, адже виконання збірок — основне призначення конвеєра збірки, і ми очікуємо робити їх багато щодня.

• Ми виявили відмінну участь колег з Azure в зонах обговорення. Хвала Microsoft за це. Особливо нас вразив Edward Thomson, PM і програміст Azure, завдяки своїй участі, прямоті та технічним поясненням.

Наслідки

Вибір Microsoft Azure DevOps, схоже, буде дорожчим (~3x) за часом і вартістю, ніж відмова від Azure.

Пов’язане

Пов’язані рішення

Якщо ми оберемо Azure DevOps, існує багато пов’язаних пропозицій, зокрема Azure Repo, Azure Pipeline тощо. Ми вважаємо, що вибір Azure Devops може полегшити використання більшої кількості можливостей Azure або ускладнити використання можливостей інших постачальників.

Ми вважаємо, що Microsoft робить великі кроки у досвіді розробника, і ми бачимо, як Microsoft робить великі придбання інструментів розробника (напр., GitHub) та залежностей (напр., Citus).

Якщо ми оберемо Azure DevOps, то можемо захотіти зробити акцент на виборі пропозицій, придбаних Microsoft, і можемо також ставитися до придбаних пропозицій з більшою обережністю/оцінкою через потенційне відторгнення «тканини», напр. ризик плинності персоналу.

Пов’язані вимоги

Ми хочемо, щоб час збірки був дуже швидким. Ми готові платити за це високу надбавку. Це тому, що ми хочемо ітерувати дуже швидко.

Ми хочемо дуже високої надійності. Ми готові платити за це високу надбавку. Це тому, що ми тестуємо сценарії використання високої цінності, зокрема фінансові транзакції, конфіденційні транзакції тощо.

Наші 4 головні KPI 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 request). Неймовірно важко працювати з людьми над запитом на злиття. Я навіть не можу вказати на «одну» конкретну проблему — у нас воно зламано всюди.»

«Azure Devops — це те, що я хочу полюбити. Інтерфейс постійно змінюється, але не виправляє базові баги, які існують віками.»

«Інструменти погано інтегровані, інтерфейс дуже повільний, немає зведеного подання активних запитів на злиття, збірок, релізів тощо для моїх улюблених репозиторіїв. Час збірки/розгортання шалено повільний.»

«Ми також намагалися використовувати Azure Boards (робочі елементи, дошки, беклоги тощо). Жах. Це повний безлад в інтерфейсі з розрізнених ідей. Замість того щоб реалізувати одну річ добре, вони реалізували два десятки речей жахливо.»

MVP з розробки для Windows

Тут MVP з розробки для Windows. Я відчуваю, що маю взяти на себе частину відповідальності за те, що не говорив гучніше про ці проблеми. Але мушу сказати, що я розчарований, чуючи, що ви «здивовані» проблемами UX. Я казав вашим людям, що UX жахливий (напр., ще до запуску), і весь час чув у відповідь «ми знаємо, ми виправляємо». Я почну оформлювати відгук і проштовхну його по каналах, залишайтеся на зв’язку. Я також місцевий (Беллв’ю), з радістю прийшов би й спробував налаштувати конвеєр для нашого відносно простого застосунку .net/wpf/uwp з відкритим кодом. Підозрюю, це відкриє очі нам обом.

Деякі приклади:

• Не можна побудувати конвеєр із git-репозиторієм, що містить субмодулі

• Виявилося неможливим редагувати PATH для якихось власних інструментів

• Досвід «Новий конвеєр» просто не має особливого сенсу, нові користувачі, клацаючи навколо, врешті опиняться не в тій документації.

Підсумок Edward Thomson (PM Azure)

Я написав код, що зливає ваші запити на злиття. Програмний менеджер 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/