Сегодня мы поговорим об Azure DevOps и процессах непрерывной интеграции/развертывания.
Можно использовать множество функций, которые интегрированы с Azure DevOps. Если подходить ко всему "как к коду" для развертывания, то вместо классического Azure DevOps в качестве решения можно применить Azure DevOps yaml deployment. В этом примере будет рассказано о шагах по развертыванию в среде kubernetes.
Во-первых, для развертываний Kubernetes можно управлять версиями во время миграций с помощью шаблона helm, а затем вы можете включить независимые от среды миграции, изменив файл values.yaml в шаблоне helm для каждого приложения и среды.
Разработанный нами шаблон может обеспечить создание общей структуры и функции отмены в возможных ошибках тестирования конечных точек в версиях. Важной частью здесь является то, как вы будете работать над сценариями тестирования и что именно вы хотите сделать.
Рассмотрим создание шаблона Helm и установку стандартов в отдельной статье.
Мы создаем файл deployment.yaml в Azure DevOps.
Кликнув на кнопку pipeline в меню, необходимо выбрать соответствующую информацию о репозитории после выбора добавления нового pipeline на открывшейся странице.
Если вы еще не создавали и не загружали репозиторий, сделайте новый пайплайн, выбрав опцию его стартового запуска. Поскольку мы уже создали yaml пайплайн, продолжим, выбрав второй вариант.
Мы подготовили этапы для работы в созданном нами пайплайне yaml.
Прежде всего, настроили наши приложения, которые были собраны в соответствии с их dockerfile, на прохождение следующих этапов.
Этапы:
Наш файл helm, который мы искусственно передали на этапе Build, изменяется на этой стадии, и вы можете сделать его готовым к работе в среде. В данном случае возможны несколько методов, и какой из них будет правильным, зависит от ваших потребностей. Для работы здесь мы берем скрытые переменные на вкладке библиотеки в пайплайне. В этом примере мы модифицировали оболочку.
Этап, на котором создаются наши файлы манифеста;
Артефакты, созданные в процессе сборки, перемещаются по этапам в средах.
Наше развертывание завершено, и мы перешли к этапу тестирования.
Для этого примера мы использовали Postman, а тесты конечных точек запускали с помощью newman в командной строке. Если наши тесты не сработают, следующий шаг автоматически откатит обратно последнее успешное развертывание для этой среды.
После этого шага стадия продакшена не переходит к соответствующему этапу, а человеку, который автоматически запустил пайплайн, отправляется электронное письмо.
Итак, что нам делать, если он успешен:
В случае успеха соответствующий сценарий отката переходит к этапу продакшена, потому что он не попадает под контроль, который мы задали внутри.
На этом шаге мы проверяем, получен ли он из ветви, появление которой ожидается, с помощью проверки после развертывания. Можно установить ветвь на этом этапе в соответствии с вашими внутренними стандартами и контролировать переходы в продакшн. Для этого примера мы использовали ветвь dev
После прохождения проверки, мы снова запускаем тест конечной точки, чтобы убедиться, что все в порядке, и посмотреть, правильно ли работает наше приложение в продакшене.
Вы можете написать дополнительно различные сценарии тестирования. Каждый написанный тестовый сценарий обезопасит ваш переход в продакшн.
"Закон Вирта: Программное обеспечение становится более медленным быстрее, чем аппаратное обеспечение становится более быстрым”
habr.com
Можно использовать множество функций, которые интегрированы с Azure DevOps. Если подходить ко всему "как к коду" для развертывания, то вместо классического Azure DevOps в качестве решения можно применить Azure DevOps yaml deployment. В этом примере будет рассказано о шагах по развертыванию в среде kubernetes.
Во-первых, для развертываний Kubernetes можно управлять версиями во время миграций с помощью шаблона helm, а затем вы можете включить независимые от среды миграции, изменив файл values.yaml в шаблоне helm для каждого приложения и среды.
Разработанный нами шаблон может обеспечить создание общей структуры и функции отмены в возможных ошибках тестирования конечных точек в версиях. Важной частью здесь является то, как вы будете работать над сценариями тестирования и что именно вы хотите сделать.
Рассмотрим создание шаблона Helm и установку стандартов в отдельной статье.
Мы создаем файл deployment.yaml в Azure DevOps.
Кликнув на кнопку pipeline в меню, необходимо выбрать соответствующую информацию о репозитории после выбора добавления нового pipeline на открывшейся странице.
Если вы еще не создавали и не загружали репозиторий, сделайте новый пайплайн, выбрав опцию его стартового запуска. Поскольку мы уже создали yaml пайплайн, продолжим, выбрав второй вариант.
Мы подготовили этапы для работы в созданном нами пайплайне yaml.
Прежде всего, настроили наши приложения, которые были собраны в соответствии с их dockerfile, на прохождение следующих этапов.
Этапы:
- Сборка
- Внедрение в разработку
- Тестирование конечной точки
- Тест на откат последней версии в случае неудачи
- Если тестирование конечной точки прошло успешно, продолжается развертывание в продакшн
- Тестирование конечной точки в продакшн
- Откат в случае неудачи
Наш файл helm, который мы искусственно передали на этапе Build, изменяется на этой стадии, и вы можете сделать его готовым к работе в среде. В данном случае возможны несколько методов, и какой из них будет правильным, зависит от ваших потребностей. Для работы здесь мы берем скрытые переменные на вкладке библиотеки в пайплайне. В этом примере мы модифицировали оболочку.
Этап, на котором создаются наши файлы манифеста;
Артефакты, созданные в процессе сборки, перемещаются по этапам в средах.
Наше развертывание завершено, и мы перешли к этапу тестирования.
Для этого примера мы использовали Postman, а тесты конечных точек запускали с помощью newman в командной строке. Если наши тесты не сработают, следующий шаг автоматически откатит обратно последнее успешное развертывание для этой среды.
После этого шага стадия продакшена не переходит к соответствующему этапу, а человеку, который автоматически запустил пайплайн, отправляется электронное письмо.
Итак, что нам делать, если он успешен:
В случае успеха соответствующий сценарий отката переходит к этапу продакшена, потому что он не попадает под контроль, который мы задали внутри.
На этом шаге мы проверяем, получен ли он из ветви, появление которой ожидается, с помощью проверки после развертывания. Можно установить ветвь на этом этапе в соответствии с вашими внутренними стандартами и контролировать переходы в продакшн. Для этого примера мы использовали ветвь dev
После прохождения проверки, мы снова запускаем тест конечной точки, чтобы убедиться, что все в порядке, и посмотреть, правильно ли работает наше приложение в продакшене.
Вы можете написать дополнительно различные сценарии тестирования. Каждый написанный тестовый сценарий обезопасит ваш переход в продакшн.
"Закон Вирта: Программное обеспечение становится более медленным быстрее, чем аппаратное обеспечение становится более быстрым”
Kubernetes и CI/CD пайплайн
Сегодня мы поговорим об Azure DevOps и процессах непрерывной интеграции/развертывания.Можно использовать множество функций, которые интегрированы с Azure DevOps. Если подходить ко всему "как к коду"...
habr.com