Справочная: что такое Continuous Delivery

Ранее мы рассказали ^[1] о Continuous Integration (CI). Продолжим с Continuous Delivery. Это — свод методов разработки ПО. Он помогает удостовериться в готовности кода к развёртыванию.

^[2]
/ Pixabay / bluebudgie ^[3] / PL ^[4]

История

Cловосочетание continuous delivery можно было увидеть ещё в agile-манифесте ^[5] от 2001 года в начале списка основных принципов: «Приоритет — решение задач заказчика с помощью непрерывной поставки актуального ПО».

В 2010 году Джез Хамбл (Jez Humble) и Дэвид Фарли (David Farley) выпустили книгу ^[6] по Continuous Delivery. По замыслу авторов, CD дополняет подход Continuous Integration ^[1] и позволяет упростить подготовку кода к развёртыванию.

После публикации книги подход начал набирать популярность и всего за пару лет стал практически общепринятым. Согласно опросу ^[7], проведенному среди более чем 600 разработчиков и ИТ-менеджеров в 2014 году, 97% технических руководителей и 84% программистов были знакомы с Continuous Delivery.

Сейчас этот подход остаётся одним из наиболее популярных. По данным исследования 2018 года, к которому привлекли сообщество IT-специалистов DevOps and Jenkins Community, его использует ^[8] половина из более чем тысячи опрошенных респондентов.

Как работает Continuous Delivery

Базис CD — готовность кода к развёртыванию. Для выполнения этой задачи используется автоматизация процесса подготовки ПО к релизу. Он должен быть стандартным для различных сред разработки, что поможет быстрее находить слабые места и оптимизировать их. Например, ускорять тестирование.

Пример процесса Continuous Delivery выглядит следующим образом:

Если за автоматизацию первых двух этапов отвечает подход Continuous Integration, то за следующие два — Continuous Delivery. Стабильность процесса обеспечивается в том числе и за счет систем управления конфигурациями ^[9]. Они мониторят изменения в инфраструктуре, базах данных и зависимостях. Само развёртывание может быть автоматизировано, а может производится вручную.

К процессу предъявляются следующие требования:

• Доступность информации о готовности к выходу в production-среду и готовность к непосредственному релизу (CD-инструменты тестируют код и дают возможность оценить эффект от изменений в релизе).
• Общая ответственность за финальный продукт. Команда продукта — менеджеры, разработчики, тестировщики — думают о результате, а не только о своей зоне ответственности (результат — рабочий релиз, который доступен для пользователей продукта).

В CD обычно применяют code review ^[10], а для сбора мнений клиентов — принцип dark launching ^[11]. Новую функцию сначала выпускают для небольшого сегмента пользователей — их опыт взаимодействия с продуктом помогает найти недочёты и баги, которые не заметили при внутреннем тестировании.

В чём выгода

Continuous Delivery помогает упростить развёртывание кода, что положительно влияет на продуктивность и снижает вероятность эмоционального выгорания сотрудников. В конечном счете это снижает и общие расходы на разработку. Например, CD помог одной из команд HP снизить ^[12] такие затраты на 40%.

Помимо этого — согласно исследованию 2016 года (страница 28 документа ^[13]) — компании, внедрившие CD, на 50% быстрее решают проблемы с ИБ, по сравнению с теми, кто не используют подход. В некоторой степени такое различие можно объяснить работой инструментов автоматизации процесса.

Ещё один плюс — ускорение выпуска релизов. В финской студии разработки непрерывная поставка помогла ^[14] увеличить скорость сборки кода на 25%.

Потенциальные сложности

Первая и основная проблема — необходимость перестраивать привычные процессы. Чтобы показать пользу нового подхода, стоит переходить на CD постепенно, начиная не с самых трудозатратных приложений.

Вторая потенциальная проблема — большое количество ветвей кода. Последствие «разветвления» — частые конфликты и очередные потери большого количества времени. Возможное решение — подход no branches ^[15].

В частности, в некоторых компаниях основные сложности возникают с тестированием — на него уходит слишком много времени. Результаты тестов зачастую приходится анализировать вручную, но возможным решением может быть распараллеливание тестов на первых этапах внедрения CD.

Также следует обучить сотрудников работе с новыми инструментами — предварительный ликбез сэкономит разработчикам силы и время.

/ Flickr / h.ger1969 ^[16] / CC BY-SA ^[4]

Инструменты

Приведём несколько открытых инструментов для Continuous Delivery:

• GoCD ^[17] — сервер для непрерывной поставки на Java и JRuby on Rails. Позволяет контролировать весь процесс поставки приложения: build—test—release. Инструмент распространяется по лицензии Apache 2.0. На официальном сайте можно найти руководство по настройке ^[18].
• Capistrano ^[19] — фреймворк для создания скриптов, автоматизирующих развертку приложений на Ruby, Java или PHP. Capistrano способен выполнять команды на удаленной машине, подключаясь к ней по SSH. Работает с другими инструментами непрерывной интеграции и поставки, например CI-сервером Integrity.
• Gradle ^[20] — мультиплатформенный инструмент, автоматизирующий весь цикл разработки приложений. Gradle работает с Java, Python, C/C++, Scala и др. Есть интеграция с Eclipse, IntelliJ и Jenkins.
• Drone ^[21] — платформа для CD на языке Go. Drone можно развернуть on-premise или в облаке. Инструмент построен на базе контейнеров и использует YAML-файлы для управления ими.
• Spinnaker ^[22] — платформа для непрерывной поставки кода в мультиоблачных системах. Разработана в Netflix, большую роль в разработке инструмента сыграли инженеры Google. Инструкцию по установке вы найдете на официальном сайте ^[23].

Что почитать в нашем корпоративном блоге:

• DevOps в облачном сервисе на примере 1cloud.ru ^[24]
• Как можно экономить с помощью нашего API ^[25]
• Эволюция архитектуры облака 1cloud ^[26]

Автор: 1cloud

Источник ^[27]