Что нужно знать о непрерывном развертывании
Непрерывное развертывание (Continuous deployment, CD) дополняет процесс непрерывной интеграции и доставки (CI/CD). Оно автоматически отправляет в продакшн все изменения, успешно прошедшие тестирование.
Что такое непрерывное развертывание?
Непрерывное развертывание доводит автоматизацию сборки, тестирования и развертывания в DevOps до логического завершения. Если изменение прошло все этапы пайплайна без ошибок, оно автоматически отправляется в продакшн без ручного вмешательства. Это позволяет быстро доставлять новые функции пользователям, не жертвуя качеством.
Непрерывное развертывание основывается на хорошо отлаженном процессе непрерывной интеграции и доставки:
- разработчики вносят небольшие изменения регулярно;
- каждый коммит запускает автоматизированное тестирование и сборку;
- cборка проходит дополнительные автоматизированные проверки в тестовых средах;
- если ошибок не обнаружено, новая версия отправляется к пользователям.
Когда CI/CD-процесс надежен, можно автоматизировать и финальный этап — развертывание. В этом случае релизы происходят незаметно и могут выполняться по несколько раз в день.
При этом непрерывное развертывание не обязательно должно стать конечной целью всех DevOps-команд. Если вы разрабатываете приложения, API или ПО, которое устанавливают вручную, частые обновления могут быть неудобны для пользователей. В таких случаях больше подойдет непрерывная доставка.
Но даже если вы решили не переходить к полностью автоматизированному пайплайну развертывания, вам могут пригодиться отдельные практики, которые можно использовать в ваших CI/CD-процессах. Давайте разберем, что включает в себя непрерывное развертывание и что важно учитывать перед его внедрением.
Непрерывное развертывание и непрерывная доставка: в чем разница?
Эти два понятия легко спутать, но непрерывное развертывание и непрерывная доставка — это отдельные части CI/CD-пайплайна. При непрерывной доставке окончательный релиз в продакшн запускается вручную, а при непрерывном развертывание релизы выполняются автоматически, когда все предыдущие этапы успешно завершены.
Сравнение непрерывного развертывания и непрерывной доставки
| Непрерывное развертывание | Непрерывная доставка | |
|---|---|---|
| Порядок релиза | Запускается автоматически каждый раз, когда изменение кода успешно прошло все этапы пайплайна. | Запускается вручную для изменений, которые успешно прошли все этапы пайплайна. |
| Частота релизов | До нескольких раз в час (зависит от размера команды и скорости пайплайна). | Обычно еженедельно или ежемесячно, но частота может быть любой на ваше усмотрение. |
| Для чего лучше всего подходит | Веб-сайты и веб-приложения. | Мобильные приложения, десктопное ПО и API. Может также служить промежуточным шагом на пути к непрерывному развертыванию. |
| Процесс тестирования | Необходима полная автоматизация и высокая надежность. Критерии качества помогают разработчикам и всем заинтересованным сторонам убедиться, что тесты выявляют любые ошибки. | Необходимо как можно шире использовать автоматизированные тесты. Менее частые релизы позволяют вручную выполнять приемочное и исследовательское тестирование. |
| Важные нюансы | Канареечное развертывание и сине-зеленые сборки позволяют минимизировать влияние любых ошибок, попавших в продакшн. Ключевую роль в выявлении ошибок в продакшене играет мониторинг. | Хотя релиз запускается вручную, сам процесс должен быть автоматизирован. Важно предусмотреть возможность отката или быстрого развертывания исправлений. |
Подробнее о различиях читайте в руководстве по непрерывной интеграции, доставке и развертывании.
Реализация
Если ваши процессы интеграции и развертывания выполняются вручную, вы периодически выполняете заморозку кода, тестирование проводится коллективно, а день релиза вся компания переживает затаив дыхание — ежечасное развертывание может показаться фантастикой.
Но на практике все больше компаний переходят к более частым релизам. Это и крупные игроки, такие как Netflix, Etsy и Amazon, и менее известные, небольшие компании. Все они переходят на непрерывное развертывание, стараясь идти в ногу с рынком. Такой подход позволил многим разработчикам ускорить процесс релиза: вместо недель или месяцев он теперь занимает всего несколько часов.
Современные пользователи ждут быстрых обновлений и отклика на свои отзывы. Непрерывное развертывание помогает выпускать новые версии регулярно без ущерба для качества.
Внедрение системы непрерывного развертывания
Продолжая процедуры непрерывной интеграции и доставки, непрерывное развертывание основывается на полностью автоматизированном процессе сборки, тестирования и развертывания. Такой подход гарантирует скорость без ущерба для качества. Однако для успешной реализации непрерывного развертывания нужно тщательно выстроить все процессы и практики.
Критерии качества
Для релиза изменений без ручного вмешательства вы должны быть уверены в надежности своего CI/CD-процесса. В частности, необходимо убедиться, что автоматизированные сборки и автоматизированные тесты эффективно выполняют проверку кода. В этом вам помогут критерии качества.
На следующий этап пайплайна переходит только код, который соответствует заранее установленным критериям. Для некоторых этапов можно установить простые пороги, например, 100% успешно пройденных юнит-тестов при покрытии 90% кода. На других этапах могут быть допустимы предупреждения, но если найдены ошибки, тест считается проваленным. Иногда может потребоваться пометить ошибки или предупреждения для проверки вручную, прежде чем этап будет считаться неудачным.
Использование критериев качества на основных этапах пайплайна помогает отслеживать процесс и управлять им, а также вести контрольный журнал для подтверждения проверок каждого релиза.
Выбор стратегии релизов
Ключевым вопросом при планировании реализации непрерывного развертывания является то, как именно будут выпускаться изменения. Если каждый релиз требует остановки серверов, это может привести к частым сбоям в работе сервисов. Поэтому часто применяют плавающие релизы. Кроме того, можно сделать выпуск своего рода расширением процедуры автоматизированного тестирования, используя канареечное развертывание.
Канареечное развертывание
Канареечное развертывание позволяет выпустить изменения только для небольшой группы пользователей, которые становятся тестировщиками в реальной рабочей среде. Проследив их поведение и метрики использования, вы сможете убедиться, что ваш релиз не привнес новых ошибок, после чего можно будет выпустить обновление для остальных пользователей.
Доверительный показатель канареечных релизов
Некоторые компании, продолжая развивать автоматизацию, ввели для канареечного релиза доверительный показатель, который автоматически сравнивает ментики с их базовыми значениями. Автоматизированное развертывание продолжается, только если показатель превышает указанный порог. Если он слишком низкий, анализ метрик создаст отправные точки для дальнейшего исследования возможных проблем.
Сине-зеленое развертывание
Сине-зеленое развертывание распространено в организациях, использующих системы непрерывного развертывания, так как оно упрощает откат к предыдущей версии в случае проблем: старый код остается в продакшене, пока вы не убедитесь, что все изменения работают корректно. Если нужно, вы можете выполнить канареечное развертывание с последующим сине-зеленым выпуском.
Мониторинг метрик в продакшене
Чтобы быстро реагировать на ошибки, которые могли быть пропущены во время автоматизированного тестирования, важно следить за состоянием системы в продакшене, независимо от того, используете ли вы сине-зеленое развертывание или выпускаете версии на замену.
Начните с определения ключевых метрик для оценки состояния системы, таких как использование диска и процессора, количество запросов или транзакций. Сравнивая эти показатели со стандартом, вы сможете быстрее обнаружить проблемы в работе ПО. После этого можно выбрать: откатить систему на предыдущую версию или устранить ошибку, пропустив новую версию через пайплайн.
На что обратить внимание
Приступая к реализации непрерывного развертывания, важно учесть все факторы, влияющие на успех этой стратегии.
Взаимодействие между командами
Процесс разработки включает не только изменения в коде. Команды, занимающиеся исследованием пользовательского поведения, маркетингом, дизайном взаимодействия, составлением документации, поддержкой, а также коммерческий и юридический отделы — все они тоже принимают участие процессе разработки.
Если заранее не обсудить с коллегами их требования к процессу релиза, они могут подумать, что автоматизация выведет разработку из-под контроля. Из-за этого они могут настаивать на ручных проверках и ревью, которые замедлят процесс и лишат вас преимуществ CI/CD. В худшем случае вся система непрерывного развертывания может быть сочтена неудачным экспериментом и отвергнута.
Создание условий для совместной работы
Для успешного внедрения непрерывного развертывания важно создать культуру сотрудничества. Вовлечение других команд на разных этапах разработки — чтобы их замечания по дизайну, безопасности, терминологии и соблюдению требований учитывались с самого начала — помогает улучшить процесс и делает его более эффективным.
Информирование заинтересованных сторон
Важно не только привлекать команды к процессу, но и обеспечить для них полную видимость того, что и когда выпускается. Настройте сервер непрерывной интеграции так, чтобы все участники процесса автоматически получали актуальную информацию. В зависимости от того, какой инструмент непрерывного развертывания вы выбрали, информацию можно распространять через панели мониторинга и уведомления.
Использование флагов функций или отдельных веток
Иногда обозримости процесса может быть недостаточно. Если вы работаете над крупным обновлением или хотите контролировать сроки релиза, выкатывать каждый протестированный коммит в продакшн — не всегда лучший вариант.
Флаги функций позволяют управлять видимостью кода в продакшене. Они помогают отслеживать его работу и быстро выявлять возможные сбои.
Другой способ — использовать отдельные ветки, которые разворачиваются в тестовых пайплайнах, не затрагивая продакшн. Такой подход сочетает принципы непрерывной доставки и развертывания, позволяя выпускать изменения более гибко.
Лучшие практики непрерывного развертывания
При грамотном подходе непрерывное развертывание помогает командам чаще выпускать обновления с минимальным количеством ошибок. Для этого важно следовать лучшим практикам: использовать метрики для оптимизации пайплайна, следить за проблемами в продакшене и вовлекать всю команду в процесс, так как CI/CD — это не только технология, но и культурный сдвиг.
Подробнее о том, как настроить CI/CD-пайплайн и повысить его эффективность, читайте в нашем руководстве.
Подводя итог
- Непрерывное развертывание — DevOps-подход, включающий в себя автоматизацию всех этапов сборки, тестирования и развертывания.
- Задача непрерывного развертывания — быстрее и чаще доставлять пользователям новую функциональность без ущерба для качества.
- Этот метод особенно удобен для веб-приложений, так как обновления применяются автоматически.
- Более частые релизы позволяют быстрее получать обратную связь от пользователей, минимизируя ущерб от ошибок, просочившихся в продакшн.
- Автоматизированные тесты, мониторинг системы в продакшне, взаимодействие с другими командами и анализ поведения пользователей помогают улучшать процесс разработки.
- Небольшие изменения и частые обновления позволяют быстрее реагировать на запросы аудитории и постоянно совершенствовать продукт.
Как вам поможет TeamCity
TeamCity упрощает настройку непрерывного развертывания с помощью настраиваемых триггеров и билд-раннеров. Настроив отдельные конфигурации сборки для развертывания, можно ограничить права пользователей на развертывание в продакшн, а гибкие триггеры сборки позволяют определить критерии релиза. Встроенная поддержка репозиториев пакетов и реестров контейнеров дает возможность управлять артефактами в процессе развертывания.
Предоставив всем заинтересованным лицам доступ к понятным панелям мониторинга в веб-интерфейсе TeamCity, вы сможете информировать их о ходе процесса. Гибкая система управления доступом защищает путь к продакшену, а встроенные журналы аудита фиксируют всю активность в пайплайне.
