Ранее мы рассказали о 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. Инструкцию по установке вы найдете на официальном сайте.
Что почитать в нашем корпоративном блоге:
- DevOps в облачном сервисе на примере 1cloud.ru
- Как можно экономить с помощью нашего API
- Эволюция архитектуры облака 1cloud
Автор: 1cloud
