Нам все больше и больше нужны автоматические вещи. Всегда одинаковые рабочие процессы могут выполняться автономно, выполнив ряд шагов. В недалеком прошлом каждый раз, когда мы хотим развернуть приложение, мы создаем и копируем эти сгенерированные файлы на сервер. Итак, нам нужен удаленный доступ к серверу, нам нужно знать, какие файлы нужно скопировать, куда мы должны их поместить и какие другие службы необходимо перезапустить. Я устал просто описывать этот процесс.
Принцип CI / CD, который означает Непрерывная интеграция и Непрерывная доставка или Непрерывное развертывание, обеспечивает гибкий метод, позволяющий группе разработчиков более часто и надежно доставлять изменения кода в свои клиентов.
Непрерывная интеграция
Есть несколько шагов, прежде чем что-либо объединится с основной веткой. Сборка приложения гарантирует отсутствие синтаксических ошибок или ошибок сборки. Запустите все существующие модульные тесты, чтобы проверить, все ли они проходят. Если все в порядке, конвейер объединит код с мастером.
Непрерывная доставка
Убедитесь, что это версия, всегда готовая к развертыванию в производственной среде.
Непрерывное развертывание
Последним шагом для согласованного конвейера CI / CD является развертывание приложения. Это на один шаг дальше, чем непрерывная доставка. Каждый раз, когда новая версия объединяется с master, запускается новый процесс развертывания.
REST API с CI / CD в Azure DevOps
Существует множество инструментов для реализации этого типа гибкого конвейера CI / CD. В этом примере я буду использовать Azure DevOps.
Настройте конвейер сборки
Я решил создать свой конвейер на YAML. Посмотрим на файл:
Эти шаги применяются каждый раз, когда я хочу объединить что-то с основной веткой, это мой триггер. Итак, когда я открываю запрос на перенос в мастер, этот конвейер запускается, поскольку это одно из моих обязательных условий для разрешения слияния.
Создайте запрос на вытягивание и проверьте изменения с помощью конвейера сборки
Этот пул-реквест пытается объединиться с мастером, поэтому запускает конвейер сборки.
Результат сборки следующий:
Успех! Теперь я могу объединить свой пулреквест с мастером, потому что условие, которое я определил, выполнено. На данный момент у нас уже есть непрерывная интеграция и непрерывная доставка. Однако мы также хотим применить эти изменения в производственной среде.
Настройте свои службы приложений в Azure
Для простоты я буду использовать Службу приложений Azure для развертывания моего REST API. У этой услуги есть бесплатный уровень.
Я создал План службы приложений для каждого приложения API. Я выбрал размер F1, который предоставляется бесплатно, но при желании могу определить лучшую конфигурацию для производственной среды. По этой причине у нас должен быть один план обслуживания для каждой среды, потому что их потребности различны.
Это действительно базовое оборудование, но его достаточно для нашего простого API. Я создам две службы приложений, одну для разработки, а другую для производства.
Настройте конвейер выпуска
На вкладке выпусков ниже конвейеров создайте новый выпуск с шаблоном для развертывания службы приложений Azure.
После этого вам нужно настроить свой первый этап конвейера выпуска. Я назвал его Разработка. Выберите подписку Azure, тип приложения, а затем службу приложений, созданную для целей среды разработки.
Теперь нам нужно определить наш артефакт, который будет запускать этот конвейер. В этом случае это будет конвейер сборки, который я представил ранее.
Поэтому каждый раз, когда создается новая сборка в основной ветке, я хочу автоматически запускать этот конвейер выпуска. Для этого нам нужно отредактировать свойства артефакта, чтобы включить непрерывное развертывание и включить только главную ветвь. Здесь вы можете определить другие ветки, которые будут включены для запуска этого процесса развертывания.
Теперь мы можем создать новый этап для производственной среды. На этом этапе я настроил условие перед развертыванием, поэтому переход не должен происходить автоматически. У условия есть один утверждающий.
Это хороший подход, позволяющий избежать запуска некоторых версий с проблемами в производство. Идея этого условия состоит в том, чтобы гарантировать, что команда будет тестировать API в процессе разработки и, в конце концов, если все пойдет так, как ожидалось, утверждающий может принять развертывание.
Ваш конвейер выпуска должен быть похож на следующее изображение:
Поздравляем, у вас есть непрерывное развертывание, все настроено!
Вывод
CI / CD - это лучшая практика DevOps, поскольку сокращает расстояние между разработчиками, которые хотят часто вносить изменения, с операциями, которым требуются стабильные приложения. Вначале этот метод требует сотрудничества между группами разработки и эксплуатации, чтобы решить, какие технологии, практики, приоритеты и политики следует применять. Как только это будет определено, обе команды узнают, как работать с конвейером CI / CD.
Помните, что это не будущее, это настоящее! Итак, если вы еще не начали его использовать, подумайте о том, чтобы начать.
