Джин Ким - Руководство по DevOps

В уже упоминавшейся книге «Непрерывное развертывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ» [103]Джез Хамбл и Дэвид Фарли дали определение термина «непрерывная доставка» . Термин «непрерывное развертывание» был впервые упомянут Тимом Фицем в записи блога «Непрерывное развертывание в IMVU: делаем невозможное — 50 развертываний в день». Однако в 2015 г. в ходе работы над этой книгой Джез Хамбл прокомментировал: «В последние пять лет наблюдается путаница вокруг терминов “непрерывная доставка” и “непрерывное развертывание”, и, безусловно, мои собственные идеи и определения изменились со времени написания книги. Каждая организация должна создавать свои варианты методов, исходя из того, в чем она нуждается. Область нашего внимания, ключевые моменты — не форма, а результаты: развертывание должно проходить с низким уровнем риска и запускаться одним нажатием кнопки по требованию».

Его обновленные определения непрерывной доставки и непрерывного развертывания звучат так:

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

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

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

В компаниях Amazon и Google большинство команд практикуют непрерывную доставку, хотя некоторые выполняют непрерывное развертывание: имеются существенные различия между командами в том, как часто они развертывают код и каким образом выполняются развертывания. Команды имеют право на выбор способа развертывания исходя из управляемых рисков. Например, команда Google App Engine часто выполняет развертывание один раз в день, в то время как Google Search — несколько раз в неделю.

Аналогично в большинстве примеров, представленных в этой книге, используется непрерывная доставка: это разработка встроенного программного обеспечения принтеров HP LaserJet, система печати счетов компании CSG, работающая на 20 технологических платформах, включая приложения для мейнфреймов, написанные на языке COBOL, разработки компаний Facebook и Etsy. Эти же шаблоны могут использоваться для разработки программного обеспечения, работающего на мобильных телефонах, наземных станциях управления космическими спутниками и так далее.

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