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

    Ранее мы рассказали о 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. Инструкцию по установке вы найдете на официальном сайте.

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

    1cloud.ru
    247,00
    IaaS, VPS, VDS, Частное и публичное облако, SSL
    Поделиться публикацией

    Комментарии 4

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

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

          0

          А можно чуть подробнее на эту тему? Какие именно проблемы возникают у DBA в мире Continuous Delivery?

            +1

            Потому что в мире chef, Jenkins, octopus, terraform и zero touch PROD, особенно в облаках, DBA старого типа (создать базу, бэкапить базу, ресторить базу, накатить скрипт) уже не нужны. Есть много людей, которые умеют делать только это, и хотят досидеть до пенсии

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое