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 — это путаница из 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 предложений, а также можем подходить к приобретённым предложениям с большей осторожностью/оценкой из-за потенциального отторжения, например риска текучести персонала.

Связанные требования

Мы хотим очень быстрого времени сборки. Мы готовы платить за это высокую надбавку. Это потому, что мы хотим итерировать очень быстро.

Мы хотим очень высокой надёжности. Мы готовы платить за это высокую надбавку. Это потому, что мы тестируем ценные варианты использования, включая финансовые транзакции, конфиденциальные транзакции и т. д.

Наши 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 занимает самое последнее место».

«UI ужасно неуклюжий везде. Хуже всего для меня запросы на слияние. Невероятно трудно работать с людьми над запросом на слияние. Я даже не могу указать на «какую-то» одну проблему — у нас всё сломано везде».

«Azure Devops — то, что я хочу полюбить. UI постоянно меняется, но не исправляет базовые ошибки, существующие уже давно».

«Инструменты плохо интегрированы, UI действительно медленный, нет панели с активными запросами на слияние, сборками, релизами и т. д. для моих любимых репозиториев. Время сборки/развёртывания безумно медленное».

«Мы также пытались использовать Azure Boards (рабочие элементы, доски, бэклоги и т. д.). Ой. Это полная путаница в UI из разрозненных идей. Вместо того чтобы хорошо реализовать одну вещь, они ужасно реализовали два десятка».

Windows Development MVP

Здесь Windows Development MVP. Чувствую, что должен взять на себя часть ответственности за то, что не говорил об этих проблемах громче. Но должен сказать, я разочарован, услышав, что вы «удивлены» проблемами UX. Я говорил вашим людям, что UX ужасен (например, ещё до запуска), и слышал в ответ «мы знаем, мы исправляем». Я начну оформлять отзывы и проталкивать их по каналам, следите за новостями. Я тоже местный (Bellevue), с удовольствием приехал бы и попробовал прогнать через конвейер наше относительно простое приложение .net/wpf/uwp с открытым исходным кодом. Подозреваю, что это откроет глаза нам обоим.

Несколько примеров:

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

• Оказалось невозможно изменить PATH для некоторых пользовательских инструментов

• Опыт New Pipeline не особенно логичен, новые пользователи, кликая туда-сюда, в итоге окажутся в не той документации.

Краткая справка об Edward Thomson (менеджер Azure)

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