Continuous Delivery ⏩ — непрерывная поставка и апгрейды, и зачем это нужно

Непрерывная поставка продукта, в основе этого процесса лежит работа короткими итерациями, циклами. Используется работа по циклу Деминга и HADI циклу.

Этот подход к разработке позволяет очень эффективно тестировать гипотезы и за счет этого добиваться потрясающих бизнес результатов.

Начните выделять циклы Continuous Delivery в своей работе. Начните тестировать гипотезы (например, делать А/Б тесты). Сфокусируйтесь на том, чтобы проверять гипотезы как можно чаще.

Цель работы по принципам Continuous Delivery — более быстрые и частые поставки новых продуктов или функций, при этом безопасно и надежно.

Зачем нужна непрерывная поставка и зачем она нужна? Она позволяет снизить время и стоимость разработки, повышает качество продукта, позволяет собирать обратную связь.

Визуально процесс работы по Continuous Delivery можно представить следующим образом:

То есть, сюда включены все классические этапы релиза, без этого не так. Но важно то, что этот процесс является циклическим и непрерывным. На картинке этого не отразить, но важно также то, что изменения здесь могут быть любыми, в том числе очень маленькими.

Все это достигается за счет автоматизации основных процессов, связанных с разработкой.

Все это позволяет делать поставки быстрее и чаще, и сфокусироваться на сборе обратной связи от пользователей, что в конечном счете позволяет делать продукт еще лучше.

• Код всегда находится в развернутом состоянии. Даже если с ним работают сотни программистов ежедневно. Таким образом, процесс интеграции и тестирования как таковые могут полностью исчезнуть.

• Больше автоматизации. Чтобы обеспечить непрерывную и быструю поставку, нам нужно максимально автоматизировать то, что может быть автоматизировано. Именно за счет автоматизации можно будет вносить даже совсем маленькие изменения.

• Код всегда должен быть доступен для релиза, по требованию. В подходе Continuous Delivery, в отличие от Continuous Deployment, релизы происходят мануально, вручную. Однако пишется таким образом, чтобы его потенциально всегда можно было пустить в релиз.

• Релизы с низкими рисками. Поскольку код всегда доступен для релиза, и изменения всегда относительно небольшие (за счет быстрой поставки всех возникающих изменений).

• Быстрый Time To Market. Быстрые поставки приводят к быстрому получению ценности бизнесом и клиентом. Кроме того, сам факт того, что поставка происходит короткими циклами, это снижает риск того, что нам придется все переделывать, что займет много времени.

• Снижение стоимости разработки. Любой продукт непрерывно совершенствуется с течением времени. Инвестируя в автоматизацию таких вещей, как билд, тестирование, развертывание — мы снижаем большое количество затрат, связанных с инкрементальными изменениями, вносимыми в продукт.

• Продукт становится лучше. За счет того, что мы собираем обратную связь с пользователей и принимаем решения на основе данных (как обратной связи, так и данных, например, А/Б тестирования) — мы можем избежать многих изменений продукта, которые имеют нулевую или отрицательную ценность.

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

• Больше счастья команды. Непрерывная поставка снижает выгорание команд. Потому что уменьшаются боли, связанными с релизами. А за счет быстрых релизов команда может лучше взаимодействовать с пользователями и получать обратную связь о том, что работает, а что — нет. То есть команда может сосредоточиться на том, о чем она заботится больше всего — на том, чтобы восхищать пользователей.

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

Однако, это не так.

Исследования, которые проводили Nicole Forsgren, Gene Kim и Jez Humble показывают, что:

• Команды с лучшими результатами делают поставки быстро и качество этих поставок более надежно.

• Использование практик Continuous Delivery, таких как контроль версий, непрерывная интеграция, автоматическое тестирование — являются условиями хороших результатов.

• Непрерывная поставка снижает и все боли, связанные с поставкой, и также снижает выгорание команды.

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

Чем лучше у вас будет внедрен Continuous Delivery, тем больше ценности получит ваш бизнес и ваши клиенты, и тем счастливее будет ваш персонал.

Подход Continuous Delivery во многом похож на DevOps, но тем не менее это разные практики.

DevOps имеет больше широкий фокус. В этом подходе внимание обращается прежде всего на культуру компании, и его целью внедрения является изменение взаимодействий между разными отделами и автоматизация.

Continuous Delivery не фокусируется на культуре. Скорее, это инструмент, который позволяет сделать сам процесс поставки более быстрым и частым. В том числе за счет автоматизации.

Continuous Delivery может органично «перетекать» в DevOps, и DevOps может начинаться с практик непрерывной поставки.

Пусть вам не покажется, что Continuous Delivery это магия и легкое решение. Скорее всего придется проделать серьезную работу, чтобы внедрить эту практику в компанию.

Continuous Delivery — это про частые и непрерывные изменения, не только в продукте, но и в том способе, котором вы его разрабатываете. Этот подход фокусируется на процессе разработки, чтобы сделать его более оптимизированным и рациональным.