Книга: Руководство по DevOps

Отделить развертывания от релизов

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

Вместе с тем слишком часто бывает, что дела идут не по плану. Мы можем столкнуться с такими производственными нагрузками, которые никогда не тестировали или даже вовсе их не предполагали. Они серьезно затруднят работу сервиса как для клиентов, так и для самой организации. Что еще хуже, для восстановления сервиса может потребоваться непростой процесс отката или в равной мере рискованная операция fix forward[92], когда мы вносим изменения непосредственно в производство, а это действительно плохой опыт для работников. Когда все наконец заработает, все сотрудники вздыхают с облегчением и радуются, что релизы ПО и их развертывание в производство происходят нечасто.

Конечно, мы знаем, что для достижения желаемого результата — гладкого и быстрого потока — необходимо выполнять развертывание чаще. Для этого нужно отделить развертывание в производственной среде от релиза версий. На практике слова «развертывание» и «релиз» часто используются как синонимы. Вместе с тем это два различных действия, служащие двум различным целям:

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

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

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

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

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

• шаблоны релиза на основе среды: в этом случае мы имеем две или более сред, где выполняется развертывание, но только одна из них получает реальный трафик от клиентов (например, благодаря настройкам средств балансировки нагрузки). Новый код развертывается в среде без реальной нагрузки, и релиз будет произведен перенаправлением трафика к этой среде. Это исключительно эффективные шаблоны, поскольку они обычно не требуют внесения каких-либо изменений в наши приложения. Они включают в себя сине-зеленое (blue-green) развертывание, канареечное развертывание[94] и кластерные иммунные системы (claster immune systems), все они будут обсуждаться ниже;

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

Оглавление книги