Как реализовать ручной шаг в конце непрерывной доставки?

13

Принятый ответ на мой вопрос « Как непрерывная интеграция связана с непрерывной доставкой / развертыванием? » Также объясняет небольшую разницу между непрерывной доставкой и непрерывным развертыванием . Похоже, что это связано с ответом на вопрос типа «Как вы хотите развернуть в производственной среде, в то время как это (эксклюзивные) варианты для выбора:

Auto (ический).
Руководство.

Я не могу себе представить, что на другой стороне стены DevOps будет бедный «оператор», которому придется делать то, что соответствует тому, что означает это «руководство» ... Мои вопросы:

Является ли моя ссылка (в моем вопросе) «распространять» или «установить» близкой к возможной реализации такого «ручного» решения? Вот соответствующая цитата моего связанного вопроса:

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

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

Каковы другие возможные реализации этого?

continuous-delivery continuous-deployment

— Pierre.Vriens
источник

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

— Черепаха

Извините, что разрушаю ваши мечты, но у нас все еще есть команда «развертывания», которая Oek должна запускать обновления БД на Db2-iSeries с помощью ARCAD, а затем шеф-поваром на серверах Tomcart для развертывания версий в рабочем режиме каждый 2 четверга с 8 до полуночи. Так что, к сожалению, иногда есть плохой оператор (это, мы надеемся, не единственная их работа)

— Tensibai

5

Лично я считаю, что distributionпрограммное обеспечение для цели является лишь промежуточным этапом развертывания - установка / активация этого программного обеспечения необходима для завершения этого развертывания.

Для меня delivery(как в continuos delivery) останавливается, когда программное обеспечение для развертывания создается и становится доступным для развертывания (например, для распространения, установки и активации)

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

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

Но в целом это просто отражает тот факт, что решение о развертывании на производстве является не просто результатом автоматического алгоритма. Вот несколько примеров таких случаев:

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

Так что я бы не рассматривал шаг вручную просто как вопрос реализации.

— Дэн Корнилеску
источник

Merci (oeps: спасибо) за то, что поделились своими взглядами на это. Похоже, у нас другое восприятие «распределения». Итак, позвольте мне добавить один сценарий: у вас есть 1 час, чтобы система онлайн-банкинга рано утром в воскресенье «активировала» 150 000 обновленных исполняемых файлов. И если по тем или иным причинам потребуется откат, то невозможно расширить это окно. Вы действительно хотите тратить свое время на «распространение», вместо того, чтобы использовать время, необходимое для этого, «на тот случай, если требуется откат?» Подумайте дважды: если это займет больше времени, чем 1 час ... вы уволены ... Ну ???

— Pierre.Vriens

ИМХО - это просто детали оптимизации или реализации самого развертывания, применимые в вашем случае (но это не делает это правилом). Тот факт, что вы выполняете часть своего развертывания до фактического закрытия старого выполнения SW, не означает, что соответствующая работа является частью этапа доставки. Это также не обязательно означает, что, как только вы начнете развертывание, вам также необходимо завершить его. Программа SW эффективно доставляется (то есть доступна / готова к развертыванию), даже если вы на самом деле не развертываете.

— Дан

2

Еще одно соображение, если вы публикуете что-то, что, как вы ожидаете, будут использовать другие проекты, развертывание также принимает значение «публикации для использования другими».

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

— hvindin
источник