Что такое непрерывная интеграция continuous integration
Справочная: как устроен процесс Continuous Integration
Сегодня мы обратимся к истории термина, обсудим сложности внедрения CI и приведем несколько популярных инструментов, которые помогут с ним работать.
/ Flickr / Altug Karakoc / CC BY / Фото изменено
Термин
Continuous Integration (непрерывная интеграция) — подход к разработке приложений, подразумевающий частое проведение сборок проекта и тестирование кода.
Цель — сделать процесс интеграции предсказуемым и обнаружить потенциальные баги и ошибки на ранней стадии, чтобы было больше времени на их исправление.
Впервые термин Continuous Integration появился в 1991 году. Его ввел в употребление создатель языка UML Гради Буч (Grady Booch). Инженер представил концепцию CI как часть собственной практики разработки — метода Буча. Он подразумевал инкрементальное уточнение архитектуры при проектировании объектно-ориентированных систем. Гради не описал каких-то требований к непрерывной интеграции. Но позже в своей книге «Object-Oriented Analysis and Design with Applications» он сказал, что задача методики — ускорить выпуск «внутренних релизов».
История
В 1996 году CI переняли создатели методологии экстремального программирования (XP) — Кент Бек (Kent Beck) и Рон Джеффрис (Ron Jeffries). Непрерывная интеграция стала одним из двенадцати ключевых принципов их подхода. Основатели XP уточнили требования к методологии CI и отметили необходимость проводить сборку проекта несколько раз в день.
В начале 2000-х методологию непрерывной интеграции стал продвигать один из основателей Agile Alliance Мартин Фаулер (Martin Fowler). Его эксперименты с CI привели к появлению первого программного инструмента в этой сфере — CruiseControl. Утилиту создал коллега Мартина — Мэттью Фоммель (Matthew Foemmel).
Цикл сборки в инструменте реализован в виде демона, периодически проверяющего систему управления версиями на изменения в кодовой базе. Решение можно скачать и сегодня — оно распространяется под BSD-подобной лицензией.
С появлением софта для CI практику начали перенимать всё больше компаний. Согласно исследованию Forrester [стр.5 отчёта], в 2009 году 86% из пятидесяти опрошенных технологических компаний использовали или внедряли CI-методы.
Сегодня практика Continuous Integration применяется организациями из самых разных индустрий. В 2018 году крупный облачный провайдер провёл опрос среди ИТ-специалистов компаний из сферы услуг, образования и финансов. Из шести тысяч респондентов 58% ответили, что используют в работе инструменты и принципы CI.
Как это работает
Основу непрерывной интеграции составляют два инструмента — система контроля версий и CI-сервер. Последний может быть как физическим устройством, так и виртуальной машиной в облачной среде. Разработчики один или несколько раз в день загружают новый код. CI-сервер автоматически копирует его со всеми зависимости и выполняет сборку. После — запускает интеграционные и юнит-тесты. Если тесты проходят успешно, то CI-система разворачивает код.
Общую схему процесса можно представить следующим образом:
Методология CI предъявляет ряд требований к разработчикам:
Сложности внедрения
Первая проблема — высокие операционные расходы. Даже если компания использует открытые CI-инструменты (о которых мы поговорим дальше), то ей все равно придется потратить деньги на поддержку инфраструктуры. Однако решением могут стать облачные технологии.
Они упрощают сборку разномасштабных компьютерных конфигураций. Плюс компании платят только за используемые ресурсы, что помогает сэкономить на инфраструктуре.
Согласно опросам [стр.14 статьи], непрерывная интеграция повышает нагрузку на сотрудников компании (по крайней мере первое время). Им приходится осваивать новые инструменты, а коллеги не всегда помогают с обучением. Поэтому приходится разбираться с новыми фреймворками и сервисами «на ходу».
Третья сложность — проблемы с автоматизацией. С ней сталкиваются организации с большим объёмом legacy-кода, который не покрыт автоматизированными тестами. Это приводит к тому, что код просто переписывают перед полноценным внедрением CI.
/ Flickr / theilr / CC BY-SA
Кто использует
Одними из первых преимущества методики оценили ИТ-гиганты. Google использует непрерывную интеграцию с середины 2000-х. CI внедрили для решения проблемы с задержками в работе поисковой системы. Непрерывная интеграция помогла оперативно обнаруживать и устранять неполадки. Сейчас CI используют все подразделения ИТ-гиганта.
Непрерывная интеграция помогает и небольшим компаниям, а еще инструменты CI используют финансовые и медицинские организации. Например, в Morningstar сервисы непрерывной интеграции помогли патчить уязвимости на 70% быстрее. А медицинская платформа Philips Healthcare смогла в два раза ускорить тестирование обновлений.
Инструменты
Вот нескольких популярных инструментов для CI:
CI, CD и снова CD: принцип работы и отличия
Несмотря на общие тенденции к автоматизации процессов разработки, все еще можно встретить компании, в которых тестирование и развертывание никак не автоматизировано. Отсутствие автоматизированных процессов влияет на скорость доставки изменений и увеличивает влияние человеческого фактора, что негативно отражается на всей компании в целом, а не только на самом отделе разработки.
В этой статье я постараюсь объяснить разницу между процессами непрерывной интеграции (Continuous Integration/CI), непрерывной доставки (Continuous Delivery/CD) и непрерывного развертывания (Continuous Deployment/CD). Мало кто разделяет два последних термина, но мы все-таки рассмотрим их по отдельности для общего понимания.
Continuous Integration (CI)
Процесс непрерывной интеграции (Continuous Integration) нацелен на автоматизированную проверку интеграции между изменениями разработчика и остальным кодом.
В этот процесс может входить статический анализ кода на уязвимости и несоответствие общим практикам разработки, сборка приложения и автоматизированное тестирование с динамической проверкой на уязвимости.
Автоматизация процессов CI позволяет ускорить процесс разработки, устраняя рутинные операции по ручной проверке интеграции с остальным кодом и сокращая нагрузку на отдел тестирования благодаря более раннему нахождению проблем интеграции с остальными частями приложения. Кроме того, у разработчика не выйдет сэкономить себе время, отправив изменения на тестирование без какой-либо проверки.
Continuous Delivery (CD)
Целью этого этапа является доставка измененной версии приложения в эксплуатацию.
Так, процессом доставки Docker-образов является обычная загрузка образа в реестр образов Docker и последующая его загрузка с хостовой машины. В системах с повышенными требованиями безопасности также может встречаться ситуация, в которой Docker-хосты не имеют доступа к каким-либо реестрам, и в таком случае может применяться доставка Docker-образов с применением команд docker save и docker load.
В системах без использования Docker доставка может быть реализована посредством SCM, apt/yum-репозиториев, ssh, S3-совместимого хранилища для образов VM (собранных с использованием, например, Packer) и многих других способов, область применения которых, опять же, во многом зависит от возникающих требований и удобства поддержки.
В вышеуказанном примере с Docker изменения будут доставлены вместе с новым образом через загрузку в реестр образов Docker.
Автоматизация процессов CD позволяет ускорить процесс доставки, исключить влияние человеческого фактора, а также сделать доставку более доступной для остальных членов команды.
Continuous Deployment (CD)
Процесс нацелен на развертывание новой версии приложения в окружение эксплуатации или тестирования. Обычно этот этап не выделяют как отдельный, развертывание включают в процесс доставки. Он зависит от предъявляемых к нему требований и используемых инструментов, но, как правило, вариант реализации процесса лежит на поверхности.
Инструменты CI/CD
Есть множество SaaS-решений, для обзора которых потребовалась бы отдельная статья. Остановимся на основных решениях, которые легко интегрируются в подавляющем большинстве случаев:
Подробный разбор процессов на вымышленном примере
Представим возможный процесс в вымышленной IT-компании и возможные требования, которые предъявляются от заинтересованных сторон. Возьмем небольшой IT-отдел, в котором присутствуют команды разработки, тестирования и эксплуатации. Рабочий процесс построен по Git-flow, а развертывание выполняется на Docker-хостах. Опишем основные требования каждой из сторон в формате таблицы.
Команда
Требования
Процессы CI/CD не должны отнимать много времени (отсутствие избыточных действий).
Требуется простой для понимания процессов CI/CD (описание процесса в виде кода с минимумом ручных действий).
По возможности процессы CI/CD во всех проектах должны быть похожи друг на друга (порог вхождения в новый проект).
Требуется возможность быстрого отката изменений в случае возникших проблем (устранение влияния человеческого фактора на процесс развертывания).
Тестирование должно быть по возможности автоматизировано (правка от разработчика уже как минимум не приводит к нарушению работоспособности остальных частей системы).
Должна быть возможность простого развертывания разных версий приложения для исследования регрессий (автоматизация процессов развертывания новых окружений).
Необходим простой способ развертывания окружения с несколькими сервисами для интеграционного тестирования без необходимости привлекать другие отделы (простота использования).
Требуется минимизация простоя между развертываниями приложений (развертывание без простоя и минимизация человеческого фактора при развертывании новых версий).
Необходима возможность быстро доставлять новую функциональность пользователям для тестирования гипотез (автоматизация процессов и отсутствие избыточных действий).
После сбора требований мы можем сформировать примерный вид процессов CI/CD в команде:
Разбор по части CI
Процесс интеграции не обязательно должен быть общим во всех случаях, намного удобнее описать различные сценарии для каждой ситуации. Давайте опишем возможные ситуации в качестве примера:
Почему нельзя построить общий процесс CI? В этом просто нет смысла – если выполнять сборку образа для интеграционного тестирования после ручного подтверждения для релизной ветки, то неминуемо случится ситуация, в которой про необходимость ручного запуска сборки просто забудут, и отдел тестирования будет проверять неактуальную версию приложения. Проводить проверку соответствия стандартам кодирования и юнит/функциональное тестирование на версии, помеченной тегом, – пустая трата времени, ведь все изменения уже есть в релизной ветке.
Чем больше будет автоматизированных задач, тем больше бессмысленной работы будет выполнено в общем процессе.
Разбор по части CD (Delivery)
В нашем случае доставкой является загрузка Docker-образа с приложением в Registry, из которого образы будут загружены на конкретный Docker-хост в процессе развертывания. Реестр может быть как общим, так и отдельным – для окружения разработки и тестирования и окружения эксплуатации. Тут все зависит от требований безопасности в конкретной компании.
Разбор по части CD (Deployment)
В нашем случае деплой в окружение эксплуатации может выполняться путем перенаправления всех новых HTTP-запросов на новый экземпляр приложения (основываясь на том, что максимальное время запроса ограничено сверху разумным лимитом для обеспечения развертывания без простоя).
Небольшим проектам или проектам без необходимости создания собственной инфраструктуры стоит обратить внимание на облачные хостинги, которые позволяют автоматизировать разработку проекта, налаживая процессы CI/CD.
Выводы
Надеюсь, теперь вы точно разобрались в отличиях CI и CD, а также поняли всю важность автоматизации данных процессов.
Подведем итог по всему вышесказанному – внедрение CI/CD само по себе является непрерывным процессом и постоянно видоизменяется в зависимости от новых требований отдельно взятой компании. В то же время процессы CI/CD требуют дополнительных инструментов и времени на внедрение, которое можно сократить, используя уже готовые сервисы для их автоматизации.
Поэтому вывод о необходимости автоматизации того или иного процесса каждый должен сделать для себя сам. Я считаю, что автоматизация рассмотренных процессов должна присутствовать в каждой компании, которая связана с разработкой.
Continuous Integration для самых маленьких
Непрерывная интеграция (англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем.
Работа с VCS
Для начала нам потребуется тестовое окружение для тестирования приложения. Если цикл тестирования достаточно длительный, а разработка ведется быстро, то разумно выделить еще и dev-окружение. Структура VCS будет отражать ваши окружения.
Все разработчики работают с основной веткой разработки, затем определенная версия фиксируется и мержится в тестовую ветку. Из тестовой ветки происходит выкладка на тестовое окружение. Производится тестирование, внесение фиксов и обратный мерж в дев. Протестированная версия отправляется в релизную ветку и от туда публикуется на продакшн. В случае нахождения ляпов на продакшне (к сожалению, такое бывает) чиним в авральном режиме из продакшн ветки и опять мержим в DEV-ветку.
В философии GIT будет немного иначе, так как при работе с GIT не принято комитить в master и даже dev. Вместо этого практикуется подход фича-бренч. Про git workflow можно почитать здесь: habrahabr.ru/post/60030. Вообще, все предлагаемые структуры VCS преследуют одну цель: избежать ситуации, когда ветка разработки не стабильна, а совершенно необходимо что-то быстро «пофиксить» или «допилить» и выложиться. При выборе своей структуры задайте себе вопрос «смогу ли я выложиться на продакшн в течение одного дня и не поломать все. Если ответ «да», то структура вам подходит.
Чтобы не пропускать ошибки на продакшн, следует сделать тестовое окружение на столько похожим на целевое, на сколько это возможно. Обычно, главная сложность это зависимость от сторонних веб-сервисов или других компонентов и операции, связанные с реальными финансовыми транзакциями.
Конфигурации
Начинающие разработчики часто впадают в ступор при отладке трансформаций Web.config’а на локальных машинах: в отличие от App.config’ов они хранятся на уровне приложения, а не в папке bin, поэтому при локальной сборке трансформации не происходит. Трансформации применяются при публикации проекта. Если вам действительно нужно обойти это ограничение, можно создать файл Web.template.config и добавить трансформацию на PostBuild приложения. Не забудьте только убрать таск трансформации из проекта, иначе трансформация будет применяться дважды.
Если в приложении используют другие технологии, все-равно лучше иметь один основной конфигурационный файл с общими настройками и дополнительные конфигурационные файлы для изменения эталонного конфига. Это избавит вас от копипаста одинаковых настроек.
Добавление файлов, отсутствующих в проекте к выкладке
Версионирование продукта
Основные подходы
Все современные CI-решения предлагают такую переменную во время сборки. Для того, чтобы этот подход работал, нужно добавить импортировать msbuild-таски из msbuildtasks.tigris.org и добавить в конце проекта:
Версионирование базы данных
SSDT-проект msdn.microsoft.com/ru-ru/data/tools.aspx
Плюсы: процесс создания и редактирования БД напоминает то, как бы вы это делали с Management Studio.
Минусы: сложность написания миграционных скриптов. Т.к. инкрементальные изменения строит сам проект, сохранность данных обеспечивается за счет pre-deploy и post-deploy-скриптов. Придется опираться на наличие/отсутствие полей в БД или «изобретать» таблицу schema version, уже реализованную в миграционных движках.
ECM7 Migrator code.google.com/p/ecm7migrator
Движок миграций с открытым кодом. Проект поддерживает хабраюзер dima117.
Плюсы: поддерживаются разные СУБД, если что-то вас не устраивает, код открыт. Мигратор поддерживается и обрастает новыми функциями. И, пожалуй, самое важное, поддерживает несколько ключей миграций в одной базе данных. Это может быть очень полезно, если ваше приложение модульное и поддерживает плагины в том или ином виде. Каждый плагин может выполнять свои миграции и при этом использовать одну БД
Минусы: нет плюшек Entity Framework Migrations.
Entity Framework Migrations blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx
Автоматизация публикации приложения
В 2012 студии система публикации web-проектов была значительно улучшена. В первую очередь это касается профилей публикации. Если вы публикуете приложение в azure, то профиль можно просто скачать с портала. В противном случае его нужно будет создать.
Как видно на скриншотах, в последней версии WebDeploy можно запустить EF-миграции с помощью всего одной галочки. Кроме этого публикация из студии умеет заменять строку подключения без использования трансформации.
Подробно про трансформации и публикации написано у Троя Ханта в статье: www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html. Сейчас нас интересует пятый шаг его гайдлайна, а именно, автоматическая публикация с помощью билд-сервера: www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html. Я большой фанат TeamCity, поэтому рассмотрим именно эту CI.
Автоматизация публикации Windows-служб
Для автоматического создания windows-служб проще всего воспользоваться командной sc:
TeamCity
Использование средств, описанных выше, сэкономит ваше время. Пойдем дальше и установим билд-сервер. Скачиваем TeamCity: www.jetbrains.com/teamcity и запускаем инсталятор, жмем везде «Ок».
Два основных понятия TeamCity – «проект» и «билд». «Проект» соответствует вашему солюшну, а под билдом понимается любая осмысленная совокупность действий над вашим проектом: будь то сборка, запуск тестов, выкладка на сервер, создание бекапов и так далее.
Автоматизированная выкладка
Первым шагом, дадим возможность выкладывать новую версию тему у кого Visual Studio не устновлена.
Основная идея, это запустить msbuild-шаг с дополнительными параметрами, создайте новый Build Definition и выберите первый шаг Msbuild. В параметры командной строки нужно передать:
Эти параметры укажут, куда нужно публиковать.
Для того, чтобы опубликовать миграции потребуется дополнительный шаг Command Line:
Сохраняете билд. Теперь кто угодно может опубликовать последнюю версию из VCS. Хорошая практика публиковаться на дев-стенд каждый день до начала рабочего дня. Таким образом вы будете отлавливать интеграционные проблемы максимально быстро.
Rolling builds
Еще одна хорошая практика – настроить триггер на запук билда, который просто будет запускать сборку вашего солюшна после каждого изменения в репо или по таймеру (например, каждые 10 минут), если над проектом работает одновременно очень много разработчиков. К этому билду следует подключить нотификацию. TeamCity поддерживает нотификации по почте, jabber, с помощью плагина для VisualStudio и Tray-приложения. Выберите вариант по вкусу. Мне по душе приложение в трее. Если билд сломался – надо срочно чинить.
Как не ломать билд
Какие бы практики вы не вводили, чтобы не делали, не существует никакого способа дать 100% гарантию, что разработчики не будут вносить в VCS код, который даже не собирается. Этот вопрос должен решаться с помощью административных мер: не уходить с работы, не проверив, что билд после твоих изменений собрался, кто сломал, тот и чинит. В одной компании, где я работал проблема со слишком часто сломанным билдом была решена правилом: сломал билд – принеси тортик. Сначала торты ели каждый день, потом перестали.
Автоматический запуск тестов
Этот шаг следует разделить на 2: юнит-тесты и интеграционные и приемочные тесты. Это важно, потому что юнит-тесты должны работать на любом окружении. Все внешние зависимости заменяются фейками.
Запуск юнит-тестов
Запуск интеграционных и приемочных тестов
Эти тесты могут зависеть от многих факторов и их запуск может предполагать накатывание бекапов или скриптов инициализации. Возможно, что вы захотите построить дополнительные отчеты о запуске таких тестов. Лучше не захламлять ваш проект с выкладкой и создать для них специальный билд. TeamCity позволяет создавать цепочки билдов. В Build triggers билда с приемочными/интеграционными тестами вы можете добавить триггер, срабатывающий при удачном прохождении билда с выкладкой. Создание такого билда для запуска приемочных тестов я описал в топике: habrahabr.ru/post/182032.
Бекапы
Создание бекапов при выкладке также может быть автоматизировано. Для бекапа файловой системы, лично я не нашел ничего лучше, чем nnbackup: www.nncron.ru/index_ru.shtml.
Команда создает аривирует в zip папку source и копирует архив в destination. Устанавливать nnbackup на целевые машины или вызывать с билд-сервера: вопрос ваших предпочтений, расположения билд сервера, сетевых издержек и безопасности.
Бекапить sql-сервер можно с помощью T-SQL
Т.е. для автоматического бекапа, вам потребуется добавить еще один Command Line-шаг. Или вы можете воспользоваться msbuild-тасками из того-же самого community-пакета, а для nnbackup написать свой msbuild-таск.
Можно пойти дальше и поставить триггер на запуск автоматического отката из бекапа, если приемочные тесты не прошли. Тогда у вас будет цепочка билдов: Выкладка » Приемочные тесты » Откат из бекапа.
Интеграция с системой ведение проекта и баг-трекером
До этого момента, мы уже сделали много полезного. Осталась одна неприятная особенность. Билд-сервер все-еще никак не связан с нашим процессом разработки. Он ничего не знает о задачах текущей итерации разработки.
TeamCity поддерживает интеграцию с YouTrack, Jira и Bugzilla. Интеграция выполняется буквально в 2 клика. После этого, указывая номер задачи в комментарии к комиту, вы увидите ссылки на соответствующие задачи в информации о билде.
YouTrack поддерживает обратную интеграцию. Основное преимущество: YouTrack будет автоматически указывать номер билда, в котором баг или фича были закрыты.
Артефакты билда
Если ваше приложение коробочное, то вам, наверняка нужно озаботиться созданием инсталляторов или deploy packages для отгрузки клиентам. Создание инсталляторов – отдельная тема, я не буду ее рассматривать в рамках этого топика. Важно, что для коробочного продукта, инсталлятор или пакет публикации – это самая важная часть релиза. Как раз для этого и придуманы артефакты билда.
Артефакт – это любой файл, являющийся значимым результатом выполнения билда. Для билдов с инсталляторами вы можете указать my-installer.exe или my-package.zip, как маску для артефактов билда и TeamCity отобразит их в соответствующей вкладке.
Вот здесь и пригодится интеграция с Issue Tracker’ом. Тестировщик или менеджер может посмотреть закрытую задачу, перейти по ссылке с билдом и забрать версию с исправлениями из артефактов билда.
В заключение хочу добавить, что процесс разработки сугубо индивидуален для каждой команды. Приведенные практики являются базой. Дальнейшее развитие инструментария должно происходить вместе с развитием продукта. Мы разрабатываем софт, чтобы делать жизнь других людей лучше. Разумно использовать софт и для того, чтобы нам самим было комфортнее работать.
Непрерывная интеграция, непрерывная доставка, непрерывное развертывание: просто матрешка
Напоминаем, что в самом начале сентября у нас вышла интересная книга Эберхарда Вольфа «Continuous delivery. Практика непрерывных апдейтов»
В любой бурно развивающейся отрасли порой бывает полезно определиться с терминами. Для тех, кто пока не успел познакомиться с книгой Вольфа, мы решили перевести небольшую статью Марко Анастасова, где доступно и внятно описаны отличия между Continuous Integration, Continuous Delivery и Continuous Deployment. Добро пожаловать под кат!
Непрерывная интеграция, непрерывное развертывание и непрерывная доставка — словно векторы, направление которых совпадает, а модуль отличается. Цель всех трех приемов одинакова: повысить надежность разработки и релизов ПО, а также ускорить разработку и релизы.
Основное отличие между тремя подходами — объем автоматизации при каждом из них. Новички часто путают эти феномены, поскольку не догадываются, что они не взаимоисключающие, а входят друг в друга как матрешки.
Ядро: непрерывная интеграция
Большинство разработчиков, вкатываясь в тему, первым делом знакомятся с непрерывной интеграцией (CI), которая заключается в следующем: все изменения, вносимые в код, объединяются в центральном репозитории (операция называется «слияние»). Слияние происходит несколько раз в день, и после каждого слияния в конкретном проекте срабатывает автоматическая сборка и тестирование.
Бывает, что перед сборкой и тестированием программу требуется скомпилировать (это зависит от языка, на котором она написана). Сегодня все чаще возникает необходимость упаковать приложение в контейнер Docker. Затем автоматические тесты проверяют конкретные модули кода, работу UI, производительность приложения, надежность API и пр. Все эти этапы в совокупности обычно называют «сборкой».
CI – это своеобразная страховочная сетка, позволяющая разработчикам избежать массы проблем перед сдачей проекта. Поэтому программисты чувствуют себя увереннее, сдавая такой код, но сама работа при этом вряд ли ускорится – возможно, развертывание так и будет выполняться вручную, подолгу, и на этом этапе также могут возникать ошибки.
Максимум, что разработчики могут сделать на первом этапе – добиться, чтобы комплект автоматизированных тестов получился исчерпывающим и достаточно стабильным, чтобы можно было спокойно пускать любую сборку, прошедшую CI, сначала в обкатку, а затем и в продакшен. Так можно обойтись без длительного ручного тестирования (QA).
Во-вторых, обратите внимание на скорость CI: я убежден, что разработчики должны получать результат CI максимум за 10 минут, иначе продуктивность падает из-за потери концентрации и частого переключения между задачами. Чтобы ускорить CI, удобно распараллеливать тесты на какой-нибудь мощной платформе.
Переход к непрерывной доставке и развертыванию
Непрерывная доставка (CD) – это практика автоматизации всего процесса релиза ПО. Ижея заключается в том, чтобы выполнять CI, плюс автоматически готовить и вести релиз к продакшену. При этом желательно добиться следующего: любой, кто обладает достаточными привилегиями для развертывания нового релиза может выполнить развертывание в любой момент, и это можно сделать в несколько кликов. Программист, избавившись практически от всей ручной работы, трудится продуктивнее.
Как правило, в процессе непрерывной доставки требуется выполнять вручную как минимум один этап: одобрить развертывание в продакшен и запустить его. В сложных системах с множеством зависимостей конвейер непрерывной доставки может включать дополнительные этапы, выполняемые вручную либо автоматически.
Непрерывное развертывание располагается «на уровень выше» непрерывной доставки. В данном случае все изменения, вносимые в исходный код, автоматически развертываются в продакшен, без явной отмашки от разработчика. Как правило, задача разработчика сводится к проверке запроса на включение (pull request) от коллеги и к информированию команды о результатах всех важных событий.
Непрерывное развертывание требует, чтобы в команде существовала отлаженная культура мониторинга, все умели держать руку на пульсе и быстро восстанавливать систему.
Мне приходилось беседовать со многими командами, практикующими непрерывное развертывание. Выяснилось, что разработчики очень ценят умение настраивать развертывание под различные среды; не менее важно, чтобы все представляли, кто, что и когда развертывал. Разработчики, практикующие CI и желающие перейти к непрерывному развертыванию, для начала автоматизируют развертывание в обкаточную среду, а развертывание в продакшен продолжают делать вручную – одним кликом.
Поскольку «непрерывная доставка» — более зыбкая концепция, нежели «непрерывная интеграция» и «непрерывное развертывание», первый термин применим в более широком контексте, чем на уровне отдельной службы или приложения – он может описывать работу целой системы и даже организации.
Например, можно сказать, что при полноценной непрерывной интеграции должна быть возможность в случае аварии с нуля создать полноценную копию продакшен-среды – одной командой. Либо условиться, что мы не сможем держать требуемый в команде темп разработки, если не укладываемся с развертыванием нового микросервиса примерно в 5 минут. Именно здесь сложно провести грань между непрерывной доставкой и DevOps. Действительно, логичнее оставить в категории DevOps такие задачи, как автоматизированное предоставление инфраструктуры (для этого применяется практика «инфраструктура как код»), логирование в масштабах всего продукта и отслеживание метрик.
Кроме того, иногда возникает путаница, что означает аббревиатура «CD» в паре «CI/CD». Четкого ответа на этот вопрос нет, но в большинстве случаев эта пара понимается как «непрерывная интеграция и непрерывная доставка». Это логично, если учесть, что непрерывное развертывание – частный случай непрерывной доставки, применимый не в каждой системе.
Небольшое резюме и заключительные мысли