Общие сведения о заданиях рабочих процессов

Завершено

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

Что такое задания рабочего процесса?

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

Задания в рабочем процессе можно использовать для разделения задач. Например, при работе с кодом Bicep проверка кода выполняется отдельно от развертывания файла Bicep. При использовании автоматизированного рабочего процесса сборку и тестирование кода часто называют непрерывной интеграцией, или CI. Развертывание кода в автоматизированном рабочем процессе часто называется непрерывным развертыванием, или CD.

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

Во многих языках программирования код необходимо собрать, прежде чем запускать. При развертывании Bicep-файла он преобразуется или транспилирован из Bicep в JSON. Инструментарий выполняет этот процесс автоматически. В большинстве случаев вам не нужно вручную создавать код Bicep для шаблонов JSON в рабочем процессе. Однако мы используем термин непрерывная интеграция, когда говорим о коде Bicep, поскольку другие части CI по-прежнему применимы, например проверка кода.

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

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

Сдвиг влево

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

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

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

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

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

Внимание

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

Определение задания рабочего процесса

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

Представьте, что вы создали Bicep-файл, который необходимо развернуть дважды: один раз в инфраструктуру в США и один раз в инфраструктуру в Европе. Кроме того, необходимо проверить код Bicep в рабочем процессе. Ниже приведен пример рабочего процесса с несколькими заданиями, который определяет подобный процесс.

Обратите внимание, что в этом примере три задания. Задание проверки аналогично заданию CI. Затем выполняются задания Развернуть в США и Развернуть в Европе. Каждое из них развертывает код в одной из сред. По умолчанию задания выполняются параллельно.

Вот как задания определяются в файле YAML рабочего процесса:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

Управление последовательностью заданий

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

Зависимости между заданиями можно указать с помощью ключевого слова needs:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deployUS: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the US region."
  deployEurope: 
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy to the European region."

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

Примечание.

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

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

Используйте ключевое слово if, чтобы указать условие, которое должно быть выполнено перед запуском задания:

name: learn-github-actions
on: [push]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Here is where you'd perform the validation steps."
  deploy: 
    runs-on: windows-latest
    needs: validate
    steps:
      - run: echo "Here is where you'd perform the steps to deploy."
  rollback: 
    runs-on: ubuntu-latest
    needs: deploy
    if: ${{ failure() }}
    steps:
      - run: echo "Here is where you'd perform the steps to roll back a failure."

В предыдущем примере, если все идет хорошо, рабочий процесс запускает задание тестирования, а затем — развертывания. Задание отката пропускается. Однако при сбое задания тестирования или развертывания рабочий процесс запускает задание отката. Мы поговорим об откате подробнее далее в этом модуле.

Задания развертывания Bicep

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

1. Анализ кода. Используйте анализатор кода Bicep, чтобы убедиться, что файл Bicep имеет корректный формат и не содержит очевидных ошибок.
2. Проверка. Используйте предварительную проверку Azure Resource Manager, чтобы выявить проблемы, которые могут возникнуть при развертывании.
3. Предварительная версия. Используйте команду what-if для проверки списка изменений, применяемых к вашей среде Azure. Пользователь должен сам изучить результаты команды "что если" и разрешить дальнейшее выполнение рабочего процесса.
4. Развертывание. Отправьте развертывание в Resource Manager и дождитесь его завершения.
5. Тест дыма. Выполните базовые проверки после развертывания на наличие некоторых важных ресурсов, которые вы развернули. Эти проверки называются тестами дыма инфраструктуры.

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

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

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

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