Разработка Майкрософт с помощью DevOps

Корпорация Майкрософт стремится использовать одну инженерную систему для создания и развертывания всех продуктов Майкрософт с твердым процессом DevOps, сосредоточенным на ветвлении Git и потоке выпуска. В этой статье описывается практическая реализация, масштабирование системы от небольших служб до крупных потребностей разработки платформы и уроки, полученные от использования системы в различных командах Майкрософт.

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

Корпорация Майкрософт также использует принципы проектирования платформы в рамках своей одной инженерной системы.

Поток выпуска Майкрософт

Каждая организация должна решить стандартный процесс выпуска кода, чтобы обеспечить согласованность между командами. Поток выпуска Майкрософт включает процессы DevOps от разработки до выпуска. Основные этапы процесса релиза включают branch, push, pull request и merge.

Branch

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

Толкать

Когда разработчик готов интегрировать и отправить изменения остальным членам команды, они отправляют локальную ветвь на ветвь на сервере и открывают pull request. Репозитории с несколькими сотнями разработчиков, работающих во многих ветках, используют соглашение об именовании для ветвей серверов, чтобы уменьшить путаницу и умножение веток. Разработчики обычно создают ветви с users/<username>/feature именем <username>своей учетной записи.

Запрос на слияние

Запросы на вытягивание контролируют объединение тематических ветвей в основную ветвь и обеспечивают соблюдение политик ветвей. Процесс создания пул-реквеста генерирует предложенные изменения и выполняет быстрый тест. Наборы тестов первого и второго уровня выполняют около 60 000 тестов менее чем за пять минут. Это не полная матрица тестирования Майкрософт, но этого достаточно, чтобы быстро обеспечить уверенность в pull requests.

Затем другие члены команды просматривают код и утверждают изменения. Проверка кода продолжается с того места, на котором закончили автоматизированные тесты, и она особенно полезна для выявления архитектурных проблем. Проверка кода вручную гарантирует, что другие инженеры команды имеют представление об изменениях и что качество кода остается высоким.

Merge

После того как запрос на слияние удовлетворяет всем правилам сборки и утвержден рецензентами, тематическая ветка объединяется в основную ветвь интеграции, и запрос на слияние завершен.

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

Различия от потока GitHub

GitHub Flow — это популярный поток выпуска разработки на основе магистралей для организаций для реализации масштабируемого подхода к Git. Однако некоторые организации считают, что по мере роста их потребностей они должны отклониться от некоторых частей потока GitHub.

Например, часто упускаемой частью GitHub Flow является то, что пулл-реквесты должны развертываться в продакшн для тестирования, прежде чем они смогут быть объединены в основную ветвь. Этот процесс означает, что все pull-запросы ожидают в очереди развертывания до слияния.

В некоторых командах несколько сотен разработчиков постоянно работают в одном репозитории, способных выполнять более 200 pull requests в основную ветвь за день. Если каждый пулл-реквест требует развертывания в нескольких центрах обработки данных Azure по всему миру для тестирования, разработчики тратят время на ожидание слияния веток вместо написания кода.

Вместо этого команды Microsoft продолжают разработку в основной ветви и объединяют развертывания в запланированные выпуски, которые, как правило, совпадают с трехнедельным спринтом.

Сведения о реализации

Ниже приведены некоторые основные сведения о реализации потока выпуска Майкрософт:

Стратегия репозитория Git

Разные команды имеют различные стратегии управления репозиториями Git. Некоторые команды хранят большую часть кода в одном репозитории Git. Код разбивается на компоненты, каждая из которых находится в собственной папке корневого уровня. Крупные компоненты, особенно старые компоненты, могут иметь несколько подкомпонентов, имеющих отдельные вложенные папки в родительском компоненте.

Дополнительные репозитории

Некоторые команды также управляют вспомогательными репозиториями. Например, агенты и задачи сборки и выпуска, расширение VS Code и проекты с открытым кодом разрабатываются на сайте GitHub. Изменения конфигурации вносятся в отдельный репозиторий. Другие пакеты, от которых команда зависит, приходят из других источников и загружаются через NuGet.

Репозиторий Mono или мульти-репозиторий

В то время как некоторые команды выбирают один монолитный репозиторий, моно-репозиторий, другие продукты Майкрософт используют подход с несколькими репозиториями . Например, Skype содержит сотни небольших репозиториев, которые объединяются в различных сочетаниях, чтобы создать множество различных клиентов, служб и инструментов. Особенно для команд, которые используют микросервисы, много-репозиторная система может быть правильным подходом. Как правило, старые продукты, которые изначально были монолитами, находят, что подход с моно-репозиторием является самым простым для перехода на Git, что отражается в их организации кода.

Выпуск ветвей

Система выпуска Microsoft поддерживает возможность сборки основной ветки в любое время. Разработчики работают в кратковременных тематических ветках, которые объединяются в main. Когда команда готова к выпуску, будь то в конце спринта или для основного обновления, они создают новую ветку выпуска от основной ветки. Ветви выпуска никогда не объединяются обратно в основную ветвь, поэтому им может потребоваться выбор важных изменений из них.

На следующей схеме показаны короткие ветви синего цвета и ветви выпуска в черном цвете. Одна ветвь с коммитом, который нуждается в cherry-pick, отображается красным цветом.

Политики и разрешения ветвей

Политики ветвления Git помогают следовать структуре релизной ветки и обеспечивать чистоту основной ветки. Например, политики ветви могут предотвратить прямые отправки в основную ветвь.

Чтобы поддерживать упорядоченность иерархии ветвей, команды используют разрешения для блокировки создания ветвей на уровне корня иерархии. В следующем примере все могут создавать ветви в папках, таких как пользователи/, компоненты/и команды/. Только менеджеры релизов имеют разрешение на создание веток в releases/, а некоторые средства автоматизации имеют разрешение на папку integrations/.

Рабочий процесс репозитория Git

В структуре репозитория и ветви разработчики выполняют повседневную работу. Рабочие среды сильно различаются по команде и по отдельности. Некоторые разработчики предпочитают командную строку, например Visual Studio, и другие работают на разных платформах. Структуры и политики, размещенные в репозиториях Майкрософт, обеспечивают надежную и согласованную основу.

Типичный рабочий процесс включает следующие распространенные задачи:

Создание новой функции

Создание новой функции является основой работы разработчика программного обеспечения. Части процесса, отличные от Git, включают просмотр данных телеметрии, создание конструктора и спецификации и написание фактического кода. Затем разработчик начинает работать с репозиторием, синхронизируясь на последнем коммите main. Основная ветвь всегда поддается сборке, поэтому её можно считать хорошей отправной точкой. Разработчик проверяет новую ветку функций, вносит изменения в код, создаёт коммит, отправляет на сервер и создаёт новый запрос на пулл.

Использование политик ветвей и проверок

После создания pull-запроса, автоматизированные системы проверяют, что новый код компилируется, не нарушает существующую функциональность и не противоречит никаким политикам безопасности или соответствия требованиям. Этот процесс не блокирует выполнение других работ параллельно.

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

Интеграция с Microsoft Teams

Многие команды настраивают интеграцию с Microsoft Teams, которая объявляет новый pull request коллегам из команды разработчиков. Владельцы любого кода, к которому внесены изменения, автоматически добавляются в качестве рецензентов. Команды Майкрософт часто используют необязательных рецензентов для кода, к которому имеют доступ многие люди, например для генерации клиента REST и общих контролов, чтобы эксперты могли просмотреть эти изменения.

Развертывание с использованием функциональных флагов

После того как рецензенты, владельцы кода и автоматизация будут удовлетворены, разработчик может завершить pull request. Если возникает конфликт слияния, разработчик получает инструкции по синхронизации для выявления конфликта, его исправлению и повторной отправке изменений. Автоматизация снова выполняется в фиксированном коде, но людям не нужно снова выходить из системы.

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

Даже если функция требует немного доработки перед вывеской, можно без опасений перейти к main, если продукт успешно собирается и разворачивается. После того, как main код становится частью официальной сборки, он снова тестируется, подтверждается его соответствие политике и подписывается цифровой подписью.

Сдвиг влево для обнаружения проблем на раннем этапе

Этот рабочий процесс Git предоставляет несколько преимуществ. Во-первых, разработка одной основной ветви практически устраняет долг слияния. Во-вторых, цикл обработки pull request предоставляет общую точку для обеспечения тестирования, код-ревью и раннего обнаружения ошибок в конвейере. Эта стратегия сдвигов влево помогает сократить цикл обратной связи для разработчиков, так как он может обнаруживать ошибки в минутах, а не в часах или днях. Эта стратегия также дает уверенность в рефакторинге, так как все изменения проверяются постоянно.

В настоящее время продукт с 200+ пулл-реквестами может создавать 300+ сборок для непрерывной интеграции в день, что составляет 500+ тестовых запусков каждые 24 часа. Этот уровень тестирования невозможен без ветвления на основе магистрали и рабочего процесса выпуска.

Выпуск на вехах спринта

В конце каждого спринта команда создает ветвь выпуска из основной ветви. Например, в конце спринта 129 команда создает новую releases/M129 ветвь выпуска. Затем команда вводит в эксплуатацию ветку спринта 129.

После ветвления ветки выпуска, главная ветка остается открытой для разработчиков, чтобы объединять изменения. Эти изменения будут внедрены через три недели в следующем этапе спринта.

Выпустить горячие исправления

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

Исправление этих проблем начинается с обычного рабочего процесса. Разработчик создает ветвь из main, получает его проверку кода и завершает запрос на вытягивание, чтобы объединить его. Процесс всегда начинается с внесения изменений в main первую очередь. Это позволяет быстро создавать исправления и проверять его локально, не переключаясь на ветвь выпуска.

После этого процесса также гарантируется, что изменение попадает в main, что критически важно. Исправление ошибки в ветви выпуска без возвращения изменения в main означает, что ошибка будет возникать во время следующего развертывания, когда ветви выпуска sprint 130 из main. Легко забыть обновить main во время путаницы и стресса, которые могут возникнуть во время сбоя. Внесение изменений в main в первую очередь означает, что они всегда должны быть как в основной ветви, так и в ветви выпуска.

Функциональность Git включает этот рабочий процесс. Чтобы сразу же внести изменения в рабочую среду, после слияния pull-запроса main, разработчик может использовать страницу pull-запроса, чтобы выбрать изменения в релизную ветку. Этот процесс создает новый pull request, нацеленный на релизную ветку, с переносом содержимого, которое только что было объединено в main.

С помощью функции cherry-pick быстро открывается pull request, обеспечивая трассируемость и надежность политик веток. Чери-пикинг может выполняться на сервере, без необходимости загружать релизную ветку на локальный компьютер. Внесение изменений, исправление конфликтов слияния или незначительные изменения из-за различий между двумя ветвями могут происходить на сервере. Команды могут вносить изменения непосредственно из текстового редактора на основе браузера или с помощью расширения Pull Request для разрешения конфликтов слияния для более продвинутого опыта.

После того как пул-реквест направляется на ветвь релиза, команда снова проводит его код-ревью, оценивает условия ветвления, тестирует пул-реквест и выполняет слияние. После объединения исправление развертывается в первом кольце серверов за считаные минуты. Оттуда команда постепенно развертывает исправление для дополнительных учетных записей с помощью кругов развертывания. По мере развертывания изменений для большего числа пользователей команда отслеживает успех и проверяет, что изменение исправляет ошибку, не вводя недостатки или замедления. Исправление в конечном итоге развертывается во всех центрах обработки данных Azure.

Переход к следующему спринту

В течение следующих трех недель команда завершает добавление функций для спринта 130 и готовится к развертыванию этих изменений. Они создают новую выпускную ветку, releases/M130 из main, и развертывают её.

В данный момент в производстве есть две ветви. При развертывании на кольцевой основе для безопасного внедрения изменений в среду эксплуатации, быстрое кольцо получает изменения спринта 130, а серверы медленного кольца остаются на спринте 129, пока новые изменения проверяются в среде эксплуатации.

Исправление изменения в середине развертывания может потребовать исправления двух разных выпусков, выпуска sprint 129 и выпуска sprint 130. Команда переносит и развертывает исправление в обе ветви релиза. Ветвь 130 повторно развертывается с исправлением на кольцах, которые уже были обновлены. Ветвь 129 повторно развертывается с исправлением на внешние кольца, которые еще не обновили до следующей версии спринта.

После развертывания всех колец устаревшая ветвь спринта 129 устраняется, так как изменения, внесенные в ветвь спринта 129 в качестве исправления, также были сделаны в main. Таким образом, эти изменения также будут внесены в releases/M130 ветке.

Сводка

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

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