Проектирование конвейера

  • 11 мин

В этом уроке вы следуйте веб-команде Tailspin, как они определяют конвейер выпуска для веб-сайта Space Game .

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

В этом модуле вы повышаете изменения с одного этапа до следующего. На каждом этапе вы развертываете веб-сайт Space Game в среде, связанной с этой стадией.

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

В этом разделе выполняются следующие действия:

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

Собрание

Вся веб-команда Tailspin собирается вместе. В разделе "Создание конвейера выпуска с помощью Azure Pipelines" команда планировала свои задачи для текущего спринта. Каждая задача связана с созданием конвейера выпуска для веб-сайта Space Game .

Напомним, что команда решила эти пять задач для их спринта:

  • Создайте конвейер с несколькими этапами.
  • Подключение веб-приложение в базу данных.
  • Автоматизация тестов качества.
  • Автоматизация тестов производительности.
  • Улучшена частота выпуска.

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

Амита и Тим смотрят Энди и Мара демонстрируют конвейер выпуска во второй раз. Они видят, что артефакт построен и установлен на Служба приложений.

Какие этапы конвейера вам нужны?

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

Тим: ОК, я понимаю идею автоматизированного конвейера. Мне нравится, как легко развернуть в Azure. Но где мы идем из этой демонстрации? Нам нужно что-то, что мы можем на самом деле использовать для наших выпусков.

Амита: Да! Нам нужно добавить другие этапы. Например, в настоящее время у нас нет места для этапа тестирования.

Тим. Кроме того, нам нужен этап, на котором мы сможем показывать новые функции руководству. Я не могу отправить ничего в рабочую среду без утверждения управления.

Энди: Абсолютно! Теперь, когда это до скорости конвейера выпуска, как мы делаем этот конвейер делать то, что нам нужно?

Мара: Давайте набросим наши требования, чтобы помочь нам спланировать наши дальнейшие шаги. Начнем с того, что у нас есть.

Мара переходит на доску и эскизы существующего конвейера.

Diagram of the whiteboard illustrating build and dev stages. Build stage produces .zip file. Dev stage deploys .zip file to Azure App Service.

Мара: этап сборки создает исходный код и создает пакет. В нашем случае этот пакет является ZIP-файлом. Этап развертывания устанавливает ZIP-файл, который является веб-сайтом Space Game, на экземпляре Служба приложений. Что отсутствует в конвейере выпуска?

Добавление этапа разработки

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

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

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

Мара обновляет ее рисунок на доске. Она заменяет "Развернуть" на "Dev" для отображения этапа разработки.

Diagram that shows the whiteboard illustrating build and dev stages. Build stage produces .zip file. Dev stage deploys .zip file to Azure App Service.

Энди: Ты поднимаешь интересную точку. Мы создадим приложение каждый раз, когда мы принудим изменения к GitHub. Означает ли это, что каждая сборка повышена до этапа разработки после его завершения?

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

Diagram that shows whiteboard illustrating build and dev stages. A condition promotes to the Dev stage only when changes happen on a release branch.

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

Что такое условия?

В Azure Pipelines используйте условие для запуска задачи или задания в зависимости от состояния конвейера. Вы работали с условиями в предыдущих модулях.

Помните, что некоторые условия, которые можно указать:

  • Только при успешном выполнении всех предыдущих зависимых задач.
  • Даже если предыдущая зависимость не завершилась ошибкой, если выполнение не было отменено.
  • Даже если предыдущая зависимость завершилась ошибкой, даже если выполнение было отменено.
  • Только при сбое предыдущей зависимости.
  • Некоторые настраиваемые условия.

Простой пример:

steps:
  - script: echo Hello!
    condition: always()

Условиеalways() вызывает безусловную печать "Hello!", даже если предыдущие задачи завершились с ошибкой.

Это условие используется, если не указать условие:

condition: succeeded()

Встроенная succeeded() функция проверка успешно ли выполнена предыдущая задача. Если предыдущая задача завершается сбоем, эта задача и последующие задачи с тем же условием пропускаются.

Здесь вы хотите создать условие, указывающее:

  • Предыдущая задача выполнена успешно.
  • Имя текущей ветви Git — выпуск.

Чтобы построить это условие, используйте встроенную функцию and(). Эта функция проверка, является ли каждая из его условий истинной. Если какое-либо условие не верно, общее условие завершается ошибкой.

Чтобы получить имя текущей ветви, используйте встроенную Build.SourceBranchName переменную. Переменные можно получить в пределах условия несколькими способами. Здесь используется variables[] синтаксис.

Чтобы проверить значение переменной, можно воспользоваться встроенной функцией eq(). Эта функция проверяет, равны ли ее аргументы.

Учитывая это условие, вы применяете это условие для запуска этапа разработки только в том случае, если текущее имя ветви — release:

condition: |
  and
  (
    succeeded(),
    eq(variables['Build.SourceBranchName'], 'release')
  )

Первое условие в функции and() проверяет, успешно ли выполнена предыдущая задача. Второе условие проверка, равно ли имя текущей ветви выпуску.

В YAML используется синтаксис канала (|) для определения строки, охватывающей несколько строк. Можно определить условие в одной строке, но мы запишем его таким образом, чтобы его было удобнее читать.

Примечание.

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

В следующем уроке при настройке этапа разработки вы работаете с более полным примером.

Более полное описание условий в Azure Pipelines см . в документации по выражениям.

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

Добавление этапа тестирования

Мара: До сих пор у нас есть этапы сборки и разработки . Что будет дальше?

Амита: Можно ли добавить этап тестирования следующим образом? Это кажется правильным местом для меня, чтобы проверить последние изменения.

Мара добавляет этап тестирования к ее рисованию на доске.

Diagram that shows the whiteboard illustrating build, dev and test stages. The Test stage deploys the build to Azure App Service.

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

Энди: Конечно. Почему мы не развертываем тест в нерабочие часы? Предположим, мы отправим вам сборку каждый день в 3 утра.

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

Мара обновляет свой чертеж, чтобы продемонстрировать, что сборка перемещается с этапа Разработки на этап Тестирования в 3 часа утра каждый день.

Diagram that shows the whiteboard showing Build, Dev, and Test stages. The schedule promotes the change from Dev to Test at 3 A.M. each morning.

Что такое триггеры?

Амита: Я чувствую себя лучше сейчас, когда мы знаем, как один этап движется к другому. Но как мы контролируем, когда выполняется этап?

Мара. В Azure Pipelines можно использовать триггеры. Триггер определяет, когда выполняется этап. Azure Pipelines предоставляет несколько типов триггеров. Ниже приведены наши варианты.

  • Триггер непрерывной интеграции (CI)
  • Триггер запроса на вытягивание (PR)
  • Запланированный триггер
  • Триггер завершения сборки

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

Что такое запланированные триггеры?

Запланированный триггер использует синтаксис cron для выполнения сборки в определенном расписании.

В системах Unix и Linux cron — это популярное средство планирования выполнения заданий через заданный интервал времени или в определенное время. В Azure Pipelines запланированные триггеры используют синтаксис cron для определения времени выполнения этапа.

Выражение cron включает поля, соответствующие определенным параметрам времени. Ниже приведены поля:

mm HH DD MM DW
 \  \  \  \  \__ Days of week
  \  \  \  \____ Months
   \  \  \______ Days
    \  \________ Hours
     \__________ Minutes

Например, это выражение Cron описывает "3 часа утра каждый день": 0 3 * * *

Выражение cron может содержать специальные символы для указания списка значений или диапазона значений. В этом примере звездочка (*) соответствует всем значениям полей "Дни", "Месяцы" и "Дни недели".

Поместите еще один способ, это выражение cron считывается следующим образом:

  • В минуту 0,
  • В третий час,
  • В любой день месяца,
  • В любом месяце,
  • В любой день недели,
  • Запуск задания

Чтобы указать 3 часа утра только в дни с понедельника по пятницу, следует использовать это выражение: 0 3 * * 1-5

Примечание.

Часовой пояс для расписания Cron — это время в формате UTC, поэтому в этом примере 3 утра означает 3 часа утра в формате UTC. На практике может потребоваться настроить время в расписании cron относительно UTC, чтобы конвейер выполнялось в ожидаемое время для вас и вашей команды.

Чтобы настроить запланированный триггер в Azure Pipelines, вам потребуется schedules раздел в файле YAML. Приведем пример:

schedules:
- cron: '0 3 * * *'
  displayName: 'Deploy every day at 3 A.M.'
  branches:
    include:
    - release
  always: false

В этом schedules разделе:

  • cron указывает выражение cron.
  • branches указывает, что развертывание выполняется только из release ветви.
  • always указывает, следует ли выполнять развертывание безоговорочно (true) или только при release изменении ветви с момента последнего запуска (false). Здесь указывается false , так как необходимо развернуть только после release последнего запуска ветвь.

Весь конвейер выполняется, когда Azure Pipelines выполняет запланированный триггер. Конвейер также выполняется в других условиях, например при отправке изменения в GitHub. Чтобы запустить этап только в ответ на запланированный триггер, можно использовать условие, которое проверка, является ли причина сборки запланированной.

Приведем пример:

- stage: 'Test'
  displayName: 'Deploy to the Test environment'
  condition: and(succeeded(), eq(variables['Build.Reason'], 'Schedule'))

Этот этап выполняется только при успешном выполнении предыдущего этапа Test, а встроенная Build.Reason переменная конвейера равна Schedule.

Далее в этом модуле вы увидите более полный пример.

Амита: Мне нравится это. Я даже не должен забрать выпуск вручную и установить его. Это готово для меня.

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

Добавление промежуточного этапа

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

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

Мара добавляет Промежуточное к ней рисование на доске.

Diagram where the whiteboard is showing the Build, Dev, Test, and Staging stages. The Staging stage deploys the build to Azure App Service.

Амита: мы используем запланированный триггер для повышения изменений с этапа разработки на этап тестирования . Но как мы продвигаем изменения с тестов на промежуточный? Это продвижение также должно произойти по расписанию?

Мара: Я думаю, что лучший способ справиться с этим будет утверждение выпуска. Утверждение выпуска позволяет вручную повысить изменение с одного этапа на следующий.

Амита: Это звучит как именно то, что мне нужно! Утверждение выпуска даст мне время протестировать последние изменения, прежде чем мы представим сборку для управления. Я могу продвинуть сборку, когда я готов.

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

Diagram where the whiteboard shows the Build, Dev, Test, and Staging stages. Changes move from Test to Staging only after approval.

Тим: Я также мог себе представить, что мы используем утверждения о выпуске для продвижения от промежуточного до производства после того, как управление выключается. Я никогда не могу предсказать, сколько времени это занимает. После того как они выключаются, я могу утвердить выпуск и повысить его до производства вручную. Но как работают утверждения о выпуске?

Что такое утверждения о выпуске?

Утверждение выпуска — это способ приостановки конвейера до тех пор, пока утверждающий не примет или отклонит выпуск. Чтобы определить рабочий процесс выпуска, можно объединить утверждения, условия и триггеры.

Помните, что в разделе "Создание конвейера выпуска с помощью Azure Pipelines" вы определили среду в конфигурации конвейера для представления среды развертывания. Ниже приведен пример существующего конвейера:

- stage: 'Deploy'
  displayName: 'Deploy the web application'
  dependsOn: Build
  jobs:
  - deployment: Deploy
    pool:
      vmImage: 'ubuntu-20.04'
    environment: dev
    variables:
    - group: Release

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

Далее в этом модуле вы определите промежуточную среду и назначите себя утверждающим, чтобы повысить уровень веб-приложения Space Game с этапа тестирования до промежуточного.

Автоматизация как мало или столько, сколько вам нужно

Azure Pipelines позволяет автоматизировать некоторые этапы при ручном управлении этапами, которые не готовы к автоматизации.

Тим: Мне нравится, как мы можем определить критерии, которые способствуют изменениям с одного этапа на следующий. Но мы определили некоторые критерии вручную в нашем конвейере. Я думал, что DevOps была о автоматизации всего.

Мара: Вы поднимаете хорошую точку. DevOps — это автоматизация повторяющихся и подверженных ошибкам задач. Иногда необходимо вмешательство человека. Например, мы получаем утверждение от управления перед выпуском новых функций. По мере того как мы получаем больше опыта работы с автоматизированными развертываниями, мы можем автоматизировать больше наших действий вручную, чтобы ускорить процесс. Например, мы можем автоматизировать более качественные проверка на этапе тестирования, поэтому Амита не должен утверждать каждую сборку.

Тим: Звучит здорово. Давайте пойдем с этим планом на данный момент и посмотрим, как мы можем ускорить систему позже.

Амита: Говоря о нашем плане, мы можем обобщить наши дальнейшие шаги?

План

Давайте рассмотрим план команды Tailspin, как они переходят к следующим шагам.

Мара: Вот конвейер выпуска, который мы хотим построить.

Мара указывает на доску.

Diagram of the final whiteboard showing the Build, Dev, Test, and Staging stages.

Мара: Чтобы свести итоги, мы делаем следующие действия:

  1. Создавайте артефакт сборки при каждом отправке изменений в GitHub. Этот шаг выполняется на этапе сборки.
  2. Повышение артефакта сборки на этапе разработки. Этот шаг происходит автоматически, когда этап сборки завершается успешно, и изменение находится в ветви выпуска.
  3. Повышение уровня артефакта сборки на этапе тестирования каждый день в 3 часа утра. Мы используем триггер по расписанию для автоматического продвижения артефакта сборки.
  4. Повышение уровня артефакта сборки до промежуточного хранения после тестов Амиты и утверждение сборки. Мы используем утверждение выпуска для повышения артефакта сборки.

После утверждения сборки можно развернуть артефакт сборки в рабочей среде.

Амита: Это будет трудно сделать? Кажется, что много работы.

Мара: Я не думаю, что это слишком плохо. Каждый этап отделен от каждого другого этапа. Этапы дискретны. Каждый этап имеет собственный набор задач. Например, то, что происходит на этапе тестирования, остается на этапе тестирования.

Каждый этап развертывания в нашем конвейере также имеет собственную среду. Например, при развертывании приложения в dev или test среда является Служба приложений экземпляром.

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

Несколько слов о качестве

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

Как оценить качество процесса выпуска? Качество процесса выпуска нельзя измерять напрямую. Что можно оценить, насколько хорошо работает процесс. Если вы постоянно изменяете процесс, это может быть признаком того, что есть что-то неправильное. Выпуски, которые последовательно завершаются сбоем в определенной точке конвейера, также могут указывать на то, что в процессе выпуска возникла проблема.

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

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

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

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

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

Наконец, при разработке процесса выпуска качества думайте о том, какие документы или заметки о выпуске необходимо предоставить пользователю. Сохранение текущей документации может быть сложной задачей. Может потребоваться использовать средство, например генератор заметок о выпуске Azure DevOps. Этот генератор — приложение-функция, которое содержит функцию, активируемую HTTP. С помощью Хранилища BLOB-объектов Azure он создает файл Markdown всякий раз, когда создается новый выпуск в Azure DevOps.

Проверьте свои знания

1.

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

2.

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

3.

Вы хотите развернуть веб-приложение в тестовой среде при каждом завершении сборки. Какой самый простой способ настроить процесс?