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

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

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

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

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

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

Ветвь

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

Явно (толкать)

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

Запрос на вытягивание

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

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

Слияние

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

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

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

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

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

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

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

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

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

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

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

Репозитории adjunct

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

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

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

Ветви выпуска

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Развертывание с помощью флагов компонентов

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

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

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

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

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

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

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

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

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

Исправления выпуска

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

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

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

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

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

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

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

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

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

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

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

Итоги

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

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