Общие сведения о средах
Конвейеры развертывания позволяют автоматизировать шаги процесса развертывания. Зачастую одни и те же действия должны повторяться в нескольких разных средах. В вашей компании по производству игрушек необходимо проверять изменения кода перед их развертыванием в рабочей среде.
В этом уроке вы узнаете, как среды Azure Pipelines помогают организовать собственный рабочий процесс.
Зачем нужны несколько сред?
В процессе развертывания вносятся изменения в ресурсы Azure, включая используемые ресурсы. Изменение ресурсов сопряжено с некоторым риском, так как результат может отличаться от ожидаемого. Более того, работа текущей системы может нарушиться.
Чтобы свести риск возникновения проблем к минимуму, перед развертыванием в рабочей среде рекомендуется испытывать изменения безопасным образом. Например, можно развернуть изменения в непроизводственных средах.
Многие организации настраивают несколько непроизводственных сред, где они постепенно развертывают свои изменения перед выпуском в рабочую среду. Каждая нерабочая среда служит своей цели и часто имеет определенные критерии качества, которые должны выполняться для переноса изменений в следующую среду. Если что-то пойдет не так, например, тест завершится неудачно, развертывание будет остановлено. По мере перехода от среды к среде растет доверие к изменениям.
Ниже перечислены распространенные среды.
Среда разработка. Обычно используется разработчиками для проверки изменений и быстрого выполнения итераций.
Среды разработки часто имеют минимальные средства контроля, так что участники команды могут легко апробировать идеи. Среду разработки можно использовать для проверки определенного параметра конфигурации для ресурса или безопасной настройки нового веб-сайта с серверной базой данных. Многие из этих изменений и пробных версий могут не выполняться в процессе развертывания, так как вы устраняете идеи, которые не будут успешными.
Более того, в некоторых командах может настраиваться отдельная среда разработки для каждого участника, чтобы они не мешали друг другу во время работы над новыми функциями.
Среды разработки иногда также называются средами песочницы.
Тестовая среда. Предназначена для ручного или автоматического тестирования изменений.
Тестовые среды можно использовать в процессе непрерывной интеграции. После развертывания изменения в тестовой среде для него можно проводить автоматические тесты. Если все автоматические тесты пройдены успешно, изменение может быть объединено с главной ветвью проекта. С помощью автоматических тестов обычно проверяются основные функциональные возможности системы, а также такие аспекты, как нарушения политик новыми ресурсами.
Вы также можете создавать специальные тестовые среды для определенных типов тестирования, таких как тестирование производительности и безопасности.
Среда интеграции. Может помочь в тестировании точек интеграции с другими системами.
В среде интеграции можно имитировать сквозные транзакции. Такие тесты часто выполняются автоматически, но многие организации также проводят ручное тестирование в этой среде.
Среды интеграции иногда также называют средами тестирования интеграции системы.
Среда пользовательского приемочного тестирования. Применяется для ручной проверки, обычно заинтересованными лицами со стороны бизнеса, а не разработчиками. При ручной проверке испытывается весь процесс работы с решением и подтверждается выполнение бизнес-требований. Затем проверяющий утверждает изменения, чтобы можно было продолжить развертывание.
Предварительная среда. Часто полностью повторяет рабочую среду: в ней используются те же номера SKU и конфигурация ресурсов. Она служит для окончательной проверки развертывания во время и после применения изменения. С ее помощью можно также проверить, следует ли ожидать простоя во время развертывания в рабочей среде.
Предварительные среды иногда также называют промежуточными.
Рабочая среда. С ней работают пользователи приложения. Это актуальная среда, которую нужно защищать и поддерживать в максимально работоспособном состоянии.
В некоторых организациях может быть несколько рабочих сред. Например, они могут располагаться в разных географических регионах или обслуживать разные группы клиентов.
Демонстрационная среда. Команда может также создавать демонстрационные среды для показа приложения пользователям, в учебных целях или для демонстрации каких-либо возможностей потенциальным клиентам. Их также может быть несколько для разных применений. Демонстрационная среда часто является урезанной копией рабочей среды с фиктивными данными клиентов.
Среды в организации
Среды могут варьироваться. В некоторых организациях используется лишь несколько сред, а в других — множество. Количество и тип используемых сред зависят от развертываемого решения, размера команды, разрабатывающей решение, и важности рабочей нагрузки.
Иногда одна среда выполняет функции нескольких перечисленных выше. В других случаях может быть сложный конвейер, который развертывается в нескольких средах, некоторые параллельно и некоторые в последовательности. Некоторые организации автоматически удаляют или выводят из эксплуатации среды, когда они не нужны, и снова развертывают их, когда в них возникает потребность.
Какие бы среды ни выбрала организация, цель состоит в том, чтобы повысить уверенность в безопасности изменения по мере продвижения по конвейеру развертывания. Если изменение не соответствует требованиям к качеству, необходимо иметь возможность прервать его развертывание в последующих средах.
В компании по производству игрушек вы решили начать с базового набора сред для веб-сайта. Помимо рабочей среды, вы создадите одну нерабочую с именем Тестовая.
Вы обновите конвейер для развертывания кода Bicep в тестовой среде и применения к нему ряда базовых тестов. Если это усилие выполнено успешно, код развертывается в рабочей среде.
Конвейерные среды
В Azure Pipelines также есть понятие среды. Среда Azure Pipelines представляет среду, имеющуюся в Azure. Определяя конвейер в YAML-файле, вы связываете задания развертывания с определенной средой. Используя среды, вы получаете некоторые другие функции в конвейере.
Проверки и утверждения
В среде Azure DevOps могут быть настроены проверки и утверждения. Каждый раз, когда среда используется в задании в конвейере, Azure DevOps гарантирует, что эти проверки и утверждения будут выполнены до запуска задания.
Например, вы можете настроить утверждения вручную для рабочей среды. Перед началом рабочего развертывания назначенный утверждающий получает уведомление по электронной почте. Он может вручную проверить, соблюдены ли все политики и правила, перед началом развертывания. Например, утверждающий может проверить, все ли работает должным образом в предварительной среде, прежде чем утверждать развертывание.
Кроме того, можно запустить автоматическую проверку, чтобы просмотреть журналы и частоту ошибок в предварительной среде после последнего развертывания. Если проверка покажет, что количество ошибок не увеличилось значительно, развертывание сможет продолжиться.
Журнал развертывания
Azure Pipelines отслеживает журнал развертываний в среде. Этот журнал позволяет легко отслеживать, что происходит в среде с течением времени. С его помощью можно даже отследить отдельный запрос функции в рабочих элементах Azure Boards или фиксацию в репозитории. Эта возможность может оказаться полезной, если возникла проблема с развертыванием и необходимо выяснить, какое изменение послужило причиной.
Безопасность
К средам можно применять другие элементы управления безопасностью. Можно ограничить конвейеры, которые разрешены использовать определенную среду. Или предотвратить случайное создание вторичного конвейера, взаимодействующего с рабочей средой.
Кроме того, можно применять разрешения пользователей для управления тем, кто может работать со средами. Разрешения могут давать право на создание новых сред, изменение существующих или просмотр сред и журнала развертываний в них.
Примечание.
Если конвейер ссылается на среду, которой еще нет, Azure Pipelines автоматически создаст ее. Эта функция может повлиять на безопасность проекта Azure DevOps, так как вы автоматически получаете разрешения на администрирование среды. Лучше создать среду самостоятельно через веб-интерфейс Azure DevOps, чтобы иметь полный контроль над ее безопасностью и не предоставить случайно лишние разрешения.
Связывание задания развертывания со средой
В определении конвейера развертывания вы создадите свойство deployment, чтобы указать задание развертывания, и укажите имя среды, в которой выполняется развертывание задания:
- stage: DeployTest
displayName: Deploy (Test Environment)
jobs:
- deployment: DeployWebsite
environment: Test
strategy:
runOnce:
deploy:
steps:
- checkout: self
В этом примере имя DeployWebsite задания связано с средой Test .
Совет
Задания также имеют другие свойства, включая стратегию развертывания, которая выходит за рамки этого модуля. Ссылка на дополнительные сведения приведена в уроке-сводке.
Среды и подключения к службам
При использовании нескольких сред каждая из них должна не зависеть от других. Например, веб-сайт в среде разработки не должен иметь доступа к базе данных в рабочей среде.
Тот же принцип применим и к конвейеру развертывания. Подключение к службе, используемое для развертывания в среде разработки, не должно иметь доступа к рабочей среде. Следование этому принципу повышает уровень защиты, делая невозможным влияние нерабочих развертываний на рабочую среду.
Для каждой среды следует создавать отдельные подключения к службам. Для каждого подключения к службе должен использоваться собственный выделенный субъект-служба с разрешениями на развертывание только в тех подписке и группе ресурсов, которые используются этой средой.
Внимание
Для каждой среды, в которой планируется развертывание, используйте отдельный субъект-службу и отдельное подключение к службе. Предоставьте субъекту-службе минимальные разрешения, необходимые для развертывания в соответствующей среде, и ничего лишнего.
Кроме того, рекомендуется разделять среды в Azure. Как минимум необходимо создать отдельную группу ресурсов для каждой среды. Во многих случаях лучше создать отдельные подписки Azure для каждой среды. Затем можно создать несколько групп ресурсов в подписке каждой среды.
Назначьте роли Azure, чтобы пользователи и субъекты-службы могли получать доступ только к тем средам, которые им необходимы. В целях безопасности ограничьте доступ к рабочей среде небольшим набором пользователей и субъектом-службой развертывания для этой среды.