Як виконати крок вручну в кінці безперервної доставки?

Прийнята відповідь на моє запитання про те, " як пов'язана безперервна інтеграція з постійною доставкою / розгортанням? ", Також пояснює невелику різницю між безперервною доставкою та безперервним розгортанням . Схоже, це пов'язано з відповіддю на питання типу "Як ви хочете розгорнути виробництво, тоді як це (ексклюзивні) варіанти, з яких можна вибрати:

• Авто (матично).
• Посібник.

Я не можу уявити, що з іншого боку стіни DevOps буде поганий "оператор", який повинен буде зробити щось, що відповідає тому, що означає "посібник" ... Мої запитання:

• Чи моє посилання (в моєму запитанні) на "розповсюдження" проти "встановлення" близьке до можливої ​​реалізації такого "ручного" речей? Ось відповідна цитата мого спорідненого питання:

• розповсюджуйте в якомусь цільовому середовищі, використовуючи щось на зразок FTP (якщо стандартні копії не можуть усунути пробіл), але ще не активуйте його в цілі. Ось, що має бути схожим / близьким до безперервної доставки , чи ні?
• встановити (або активувати ) в якомусь цільовому середовищі в поєднанні з такими речами, як прив'язка, зупинка / запуск операцій і т. д. Ось що має бути подібним / близьким до безперервного розгортання , чи ні?

• Які ще можливі його реалізації?

Особисто я вважаю, що distributionпрограмне забезпечення є цільовим лише посередницьким кроком розгортання - встановлення / активація цього програмного забезпечення необхідна для завершення розгортання.

Для мене delivery(як і в continuos delivery) зупиняється, коли створене програмне забезпечення для розгортання і доступне для розгортання (тобто для розповсюдження, встановлення та активації)

Отже, щоб відповісти на ваше перше запитання, ні, я не вважав би розподіл та встановлення таким, що відображає ручний крок, що відрізняє безперервну доставку від безперервного розгортання.

Так, у деяких (сподіваємось, рідкісних) випадках крок вручну - це лише остаточне рішення людини щодо впровадження у виробництво, що відображає недовіру культури до автоматизації процесів та ментальний комфорт, щоб мати двічі перевірку та підписання рішення про розгортання (таким чином припускаючи відповідальність за це), навіть якщо це рішення виноситься виключно на основі алгоритму, який можна автоматизувати (наприклад, підрахунок результатів тестування пропуск / збій).

Але загалом це просто відображає той факт, що рішення про виконання розгортання у виробництві - це не просто результат автоматизованого алгоритму. Ось декілька прикладів таких випадків:

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

Тому я б не розглядав крок вручну просто як проблему з впровадженням.

Одне додаткове враження, якщо ви публікуєте те, що очікуєте, що інші проекти споживають, розгортання також має значення "публікація для використання іншими"

Розглянемо робочий процес, де ви розгортаєте бібліотеку до загального сховища артефактів. Ця частина процесу може бути частиною того, що ви розгортаєте інший компонент, який вимагає цього артефакту під час збирання, або це може бути просто оновлення загальної бібліотеки. Але незалежно від цього артефакту, його життєвий цикл не обов'язково закінчується тим, що він стане доступним для споживання іншим, але розгортання цього артефакту у сховищі артефактів може бути завершальним етапом роботи розробників після того, як вони вирішили скоротити нова версія випуску і раніше, ніж інші зможуть спокійно споживати нову версію.