Именно в непрерывном развертывании DevOps-технология автоматизации сборки, тестирования и развертывания получила свое наибольшее логическое развитие. Если изменение успешно проходит все предыдущие стадии пайплайна, оно автоматически (без ручных вмешательств) попадает в продакшн. Непрерывное развертывание позволяет быстро доставлять пользователю новую функциональность и не жертвовать при этом качеством.
Непрерывному развертыванию предшествует стадия непрерывной интеграции с тщательным тестированием и стадия непрерывной доставки. Разработчики делают регулярные коммиты небольших изменений в основную ветку (master), после чего выполняется автоматическая сборка и тестирование, развертывание на препродакшн-окружениях, и, если проблем не обнаруживается, изменения наконец попадают в продакшн. С устойчивым и надежным пайплайном непрерывного развертывания релизы становятся обычным делом, вы сможете выполнять их по несколько раз в день.
И хотя автоматизация финального выпуска в продакшн подойдет не всем проектам, вам могут пригодиться отдельные шаги, реализующие непрерывное развертывание. В этой статье мы рассмотрим, из чего состоит этот процесс, и обсудим моменты, которые следует учесть, если вы решаете сделать финальный шаг в мир полной непрерывности.
Если ваши процессы интеграции и развертывания выполняются вручную, вы периодически выполняете заморозку кода, тестирование проводится коллективно, а день релиза вся компания переживает затаив дыхание — ежечасное едва заметное развертывание может показаться фантастикой.
Однако на практике оказывается, что к этому подходу прибегает множество организаций, от гигантов вроде Netflix, Etsy и Amazon до небольших компаний, старающихся идти в ногу с рынком. Начав использовать систему непрерывного развертывания, эти компании смогли ускорить процесс релиза: вместо недель (и даже месяцев) он теперь занимает всего несколько часов. Возможность быстро выпускать новую функциональность и оперативно реагировать на обратную связь начинает играть большое значение во многих отраслях.
Продолжая процедуры непрерывной интеграции и доставки, непрерывное развертывание основывается на полностью автоматизированном процессе тестирования и развертывания — именно это позволит вам быть уверенными, что вы не жертвуете ради скорости качеством. Однако это лишь фундамент для построения эффективной реализации непрерывного развертывания.
Ключевым вопросом при планировании реализации непрерывного развертывания является то, как именно будут выпускаться изменения. Помимо использования плавающих релизов (вместо того, чтобы выключать серверы, чтобы не допустить перебоев в работе онлайн-сервисов), вы также можете сделать выпуск своего рода расширением процедуры автоматизированного тестирования.
Канареечное развертывание делает изменения доступными лишь для небольшой доли пользователей, делая их таким образом невольными тестировщиками системы в продакшне. Проследив их поведение и метрики использования, вы сможете убедиться, что ваш релизом не привнес новых ошибок, после чего можно будет выпустить обновление для остальных пользователей.
Некоторые компании, продолжая развивать автоматизацию, ввели для канареечного релиза доверительный показатель, который автоматически сравнивает множество метрик с их базисными значениями. Выпуск продолжит выполняться автоматически, пока показатель превышает определенный порог, а анализ метрик будет создавать отправные точки для дальнейшего исследования возможных проблем.
Сине-зеленое развертывание распространено в организациях, использующих системы непрерывного развертывания, поскольку оно упрощает процедуру отката к предыдущей версии, необходимого на случай возникновения проблем: для этого старый код продолжает храниться в продакшне, пока вы не убедитесь, что все изменения работают должным образом. Если нужно, вы можете выполнить канареечное развертывание с последующим сине-зеленым выпуском.
Независимо от того, делаете ли вы сине-зеленое развертывание или выпускаете версии на замену, если вы хотите иметь возможность быстро реагировать на ошибки, проскользнувшие через процесс релиза, вам необходимо следить за состоянием системы в продакшне.
Следя за метриками, отражающими состояние вашей системы (начиная с дискового пространства и использования процессора, заканчивая количеством запросов и транзакций), и сравнивая их со стандартом, вы будете раньше узнавать о проблемах в поведении ПО. Далее вы сможете выбрать между откатом к предыдущей версии и исправлением проблемы (с прохождением новой версии через пайплайн).
Приступая к реализации непрерывного развертывания, вы также должны знать о тех проблемах, которые могут возникнуть.
Процесс разработки включает не только изменения в коде. Команды, занимающиеся исследованием пользовательского поведения, маркетингом, дизайном взаимодействия, составлением документации, поддержкой, а также коммерческий и юридический отделы — все они тоже принимают участие процессе разработки.
Если вы не подготовили почву вместе с коллегами и не поинтересовались, какие у них требования к процессу релиза, у них может возникнуть ощущение, что переход на непрерывное развертывание выведет разработку из-под контроля. В ответ они могут ввести ручные проверки и стадии ревью, которые замедлят процесс, либо и вовсе посчитать систему непрерывного развертывания неудачным экспериментом и отказаться от нее.
Важно создать культуру сотрудничества. Вовлечение других команд в процесс разработки, использование их вклада (в проектирование, вопросы безопасности, терминологию или соответствие требованиям) на ранних стадиях процесса — еще один пример того, как короткие циклы обратной связи делают процесс разработки более эффективным. Помимо привлечения команд к участию в процессе, важно обеспечить им обозримость процесса (что выпускается и когда). Информировать коллег можно автоматически с помощью CI-сервера — инструмента непрерывного развертывания, который будет распространять информацию через панели мониторинга и уведомления.
Иногда обозримости процесса может быть недостаточно. Если вы работаете над большим объемом новой функциональности или вам нужно контролировать сроки релиза, выполнять развертывание в продакшн каждого коммита, прошедшего все тесты, — не совсем идеальный вариант.
Эту проблему решают флаги функций, позволяющие контролировать, будет ли пользователя доступен тот или иной фрагмент кода или нет: при этом код будет находиться в продакшне, и вы сможете следить за его поведением. Другой подход заключается в использовании специальных веток, развертывание которых выполнялось бы в отдельных пайплайнах, не публикующих изменения в продакшн, — своего рода объединение технологий непрерывной доставки и непрерывного развертывания.
При правильном подходе непрерывное развертывание может помочь командам автоматизировать развертывание программного обеспечения. Следование лучшим практикам непрерывного развертывания может помочь вам оптимизировать процесс и добиться лучших результатов. Например, важно регулярно следить за работой пайплайна и использовать метрики для своевременного обнаружения проблем. Также имеет смысл привлекать к построению эффективного CI/CD-пайплайна всю команду.
Эти два понятия легко спутать, но непрерывное развертывание и непрерывная доставка являются отдельными частями CD-части CI/CD-пайплайна. While continuous delivery is focused on automating the steps required to deliver the software to users (for example, by automating builds, test automation, etc.), continuous deployment is a logical continuation of the process, automating the release of the software to end users provided that all necessary criteria are met.
Непрерывное развертывание использует максимум автоматизации, чтобы доставлять функциональность пользователю быстро и без ущерба качеству. Важной частью этой DevOps-технологии является регулярная и быстрая обратная связь. Автоматизированные тесты, мониторинг системы в продакшне, контакт с другими командами и понимание поведения пользователей — все это служит основой процесса разработки ПО. Выполняя работу небольшими частями и делая частые релизы, вы сможете вносить коррективы в зависимости от обратной связи пользователей и непрерывно совершенствовать свой продукт.