Continuous Integration (CI) - непрерывная интеграция, это практика разработки программного обеспечения, при которой члены команды часто интегрируют свою работу. Интеграция это слияние новой версии кода со стабильной и проверка, что при этом ничего не сломалось. Следуя этой практике, обычно, каждый сотрудник интегрирует изменения по крайней мере ежедневно, что приводит к нескольким интеграциям в день. Каждая интеграция проверяется автоматизированной сборкой (включая тестирование), чтобы как можно быстрее обнаружить ошибки интеграции. Многие команды пришли к выводу, что такой подход приводит к значительному сокращению проблем интеграции и позволяет команде быстрее разрабатывать целостное программное обеспечение. Подробнее можно почитать у Мартина Фаулера. В современном IT многие знакомы с CI, но мало кто знает, что скрывается за аббревиатурой CD.
Собеседуя Ops’ов в OneTwoTrip, среди прочего я спрашивал что такое CI, а потом что такое CD. Не смотря на то, что зачастую люди могли дать какой-либо вразумительный ответ, почти никто не мог рассказать разницу между Continuous Delivery и Continuous Deployment. Я и сам постоянно забываю правильный ответ, поэтому решил написать эту заметку. Для кого-то это может быть критично, например если на собеседовании вам попадется такой же поехавший как я.
Разница между Continuous Delivery и Continuous Deployment очень маленькая. Представим два пайплайна для одного и того же приложения. В каждом есть шаги:
- Source Control - внесение изменений в систему контроля версий ПО
- Build - сборка приложения и прогон unit тестов
- Staging - деплой на тестовое окружение, прогон интеграционных, нагрузочных и других тестов
- Production - деплой на окружение с пользователями
Каждый пайплайн запускается автоматически по триггеру из системы контроля версий. В случае Continuous Deployment каждый следующий шаг, будет выполнен автоматически если предыдущий был успешный, включая деплой на Production.
Если же у вас Continuous Delivery, то шаги будут выполняться автоматически только в безопасной среде, а перед деплоем на Production пайплайн остановится и будет ждать ручного подтверждения. Механизм, как это будет реализовано может быть разным. От самого простого, когда ответственный человек должен зайти в пайплайн и нажать кнопку Next, до интерактивного бота с кнопками в корпоративном мессенджере.
Зачем нужен ручной апрув перед деплоем на Production, ведь это тормозит пайплайн т.е. доставку фич и исправлений багов? Вопрос резонный, но ответ такой же. Не все проекты одинаковые, есть такие в которых решение о деплое на Production должно быть принято человеком ответственно и осознанно. Когда бизнес сложный, с большим количеством факторов и нельзя переложить выбор “деплоить или нет” на пару алгоритмических критериев, тогда и применяется Continuous Delivery, а не Continuous Deployment.
Для простоты я сделал специальную диаграмму, она доступна по короткой ссылке doam.ru/cdvscd.
