Что такое непрерывная доставка?

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

Чтобы перенять это мышление, попробуйте изменить понимание того, что такое «готовность»: новая возможность (или исправление ошибки), которую вы реализуете, готова не тогда, когда вы передаете написанный код следующей команде по цепочке, а тогда, когда она попадает в продакшн. Если на какой-либо стадии пайплайна обнаружится ошибка, быстрое информирование и совместная работа позволят быстрее решить проблему, чем если бы вам пришлось писать длинные отчеты для последующего одобрения комиссией. Вот что представляет собой непрерывная доставка.

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

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

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

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

С CI/CD-пайплайном у вас появляется возможность сотрудничать с коллегами, участвующими процедуре релиза, и учитывать их потребности в пайплайне. Вероятно, у вас уже был опыт совместной работы с коллегами по QA при разработке автоматизированных тестов.

Включив в процесс исследовательское тестирование в подходящем тестовом окружении (максимально приближенном к продакшн-окружению), вы сможете находить неожиданные ошибки. Впоследствии эти ошибки можно покрыть автоматизированными тестами. Это важный этап непрерывной доставки.

Нередко считают, что команда по информационной безопасности препятствует частым релизам, поскольку ей требуется время для проведения аудитов по безопасности и для составления длинных отчетов. Используя подход DevSecOps, вы сможете внедрить требования по безопасности прямо в пайплайн.

То, какие именно вам потребуются шаги, окружения и тесты, зависит от архитектуры вашего ПО и от организационных приоритетов. Если ваша система основана на микросервисах, вы можете воспользоваться имеющейся архитектурой и запускать тесты для сервисов параллельно, а затем объединять их в более сложные интеграционные и сквозные тесты.

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

Как только вы определитесь со стадиями пайплайна (в том числе с тестами для них), нужно будет составить по процессу скрипт — так вы обеспечите надежность и повторяемость. Чтобы избежать неконсистентности, в преподакшн- и продакшн-окружении необходимо разворачивать именно тот артефакт, который вы получили в результате выполнения стадии CI.

В идеале тестовые окружения должны обновляться с появлением каждой новой сборки. Используя контейнеры и подход Infrastructure As Code, вы сможете настраивать и сбрасывать окружения при помощи скрипта.

Если ваш пайплайн включает тестовые окружения для команд поддержки, продаж или маркетинга (для ознакомления с новыми возможностями), то, вероятно, вы захотите обновлять эти окружения вручную, чтобы не прерывать ничью работу. Что касается финального релиза в продакшн, для него тоже полезно иметь скрипт развертывания — так ваш процесс всегда будет быстрым и консистентным.

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

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

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

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

Создание CI/CD-пайплайна может представляться очень трудоемкой задачей, поначалу требующей от команды больших усилий. Однако при правильном подходе CI/CD позволит команде тратить на доставку ПО в десять раз меньше времени. Тем не менее, чтобы правильно организовать рабочий процесс, необходимо следовать лучшим практикам CD.

Непрерывная доставка включает в себя автоматизацию ручных шагов, необходимых для выпуска ПО. Однако этот процесс не предполагает полную автоматизацию выпуска ПО — это задача непрерывного развертывания. Непрерывная доставка и непрерывное развертывание — это две части единого CI/CD-процесса.

Подробнее о непрерывной доставке и развертывании

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

И хотя в некоторых организациях предпочитают выполнять финальный шаг процедуры релиза вручную, для других логичным завершением CI/CD-пайплайна является автоматизация релиза в продакшн — технология, называемая непрерывным развертыванием.