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

ПРАВИЛА: Уверенность в тестах, верный выбор контролируемого объекта, создание культуры сотрудничества, контроль выпуска, контроль производства, контроль паплайна. ИНСТРУМЕНТЫ: Контроль версий, автоматизация сборки, развертывание.

полная автоматизация цикла развертывания, обеспечение обратной связи, возможность расширения тестирования

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

В этих целях используется три основных стратегии автоматизации и управления:

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

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

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

Непрерывное развертывание (CD) на текущий момент нашло свое максимальное развитие в DevOps–технологии.

НР по сути автоматизирует, делает непрерывным весь процесс. Предположим, изменение успешно проходит все предыдущие стадии (см. выше). В момент фиксации кода автоматически, без чьего–либо вмешательства, срабатывает триггер и обновления отправляются в производство (потребителям, клиентам, пользователям) в режиме реального времени. Таким образом, моментом доступности «улучшения» является момент завершения проверки и тестирования изменения кода.

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

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

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

Уверенность в тестах. Здесь нужно отдавать приоритетность исправлению проблем сборок и паплайнов перед разработкой новых функций.

Верный выбор контролируемого объекта. Для снижения рисков потерь преимуществ непрерывной интеграции, а также для возможности продолжения процесса разработки ПО следует контролировать и ограничивать «поле зрения» потребителя.

Очень важно иметь в виду, что разработка ПО ведется многими смежными отделами, например, дизайнерами. Несвоевременный запуск изменений может привести к их ручным проверкам и т.п. В этих случаях два пути: первый – привлечение команды к участию, информирование через CI–сервер; второй — аналогично выбирать контролируемый объект и расставлять флаги функций для снижения обозримости процесса.

Как уже говорилось, CD предполагает предварительную проверку и тестирование. Возникает ложное ощущение потери контроля над последующим автоматическим процессом доставки обновления. Быть уверенными в себе нам позволяет, например, тестирование на группе клиентов (Релизы Canary) или же управление переходом на обновленный продукт (сине–зеленое развертывание).

Вам предстоит осуществлять постоянный мониторинг статистики. Любые отклонения должны быть оперативно и пристально рассмотрены до их обнаружения клиентом.

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

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

Итак, основа для начала CD — автоматизация сборки, качественные тестирование и развертывание. Далее следует сам процесс выпуска изменений. Об этом мы уже вскользь говорили в прошлом пункте в разделе «контроля выпуска».

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

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

Сине–зеленое развертывание позволяет вернуться к предыдущей версии при выявлении ошибок за счет сохранения старого кода в производстве до момента полного удостоверения должной работы изменения.

Зачастую используют вместе оба вида развертывания для возможности своевременного возврата к предыдущей версии и исправления проблемы.

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

Контроль версий. Контроль версий (КВ) позволяет регистрировать историю обновлений и дает возможность «откатиться» к исходному коду. Благодаря КВ создаются ветки кода для возможности изменения кода без риска потерь.

Наиболее популярным инструментом контроля версий является система управления версиями Git и веб–сервис GitHub. Его основная идея — возможность регистрирации кода в репозитории и дальнейшим пользованием типовыми функциями инструмента контроля версий.

Автоматизация сборки. Регистрация кода в системе контроля требует последующей сборки кода. Этот инструмент требует автоматизации и должен иметь функцию тестирования. Выбор инструмента автоматизации сборки диктуется самим проектом. Например, MSBuild для ПО Microsoft, Team Foundation Server и Visual Studio Team Services (VSTS), Jenkins, TravisCI и TeamCity актуальны для проектов с открытым кодом.

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

Инструменты СD за счет скриптов развертывают код, интегрируют и обязательно тестируют его в производственной системе. Инструменты тестирования дают возможность самому разработчику совершить запуск и тестирование кода. Обычно для этого используют Jenkins, AWS CodeDeploy, Octopus Deploy и VSTS.

Также, используются следующие инструменты:

• управления автоматизацией и настройкой Puppet и Ansible при развертывании и конфигурирование обычно;
• мониторинг изменений, вызванных кодом (например, AppDynamics и Splunk)
• реагирования и администрирования инцидентов (например, PagerDuty).

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

Также преимуществом CD является возможность расширения тестирования. Но здесь же код должен быть добросовестно спроектирован, а тесты – своевременны.

CD обеспечивает постоянную обратную связь в формате «обновление пользователям – быстрое информирование о дефектах на ранних стадиях».

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