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


/ Pixabay / bluebudgie / PL

История


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

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

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

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

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


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

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



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

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

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

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

В чём выгода


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

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

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

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


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

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

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

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


/ Flickr / h.ger1969 / CC BY-SA

Инструменты


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

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

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

Комментарии (2)


  1. questor
    24.04.2019 21:00

    А статья-то где? Вижу только попытку рассказать о CD в формате 140 символов.


  1. Tzimie
    24.04.2019 22:13
    +1

    В новом мире нет места DBA. Многие мои коллеги (кто в летах, кто умеет только бэкапы делать) не видят себя в этом новом мире, и в панике.