Зробіть наступне розгортання повторюваним

Зберіть ідентифіковані вхідні дані

Використайте застосунок, який ви можете зібрати в непродакшен-середовищі, доступ до джерел і його реєстру артефактів, версійовану схему конфігурації та зовнішнє сховище секретів. Зберігайте відомий працюючий реліз. Це вхідні дані для вашої автоматизації; PrivacyNodes не надає API розгортання чи засіб запуску конвеєрів через цей вебсайт.

Закріпіть артефакт замість покладання на змінний тег, як-от latest. Docker документує закріплення дайджесту для ідентифікації точного базового образу з потребою навмисно переглядати оновлення. Відтворюваність і патчування — обидві відповідальності: зберігати старий уразливий образ назавжди не є планом обслуговування.

Технічна довідка: Найкращі практики збірки Docker.

Напишіть запис про реліз перед зміною трафіку

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

# Illustrative release record — no credentials
release: reports-api-review-01
source_revision: REVISION_TO_REVIEW
artifact_digest: DIGEST_FROM_YOUR_REGISTRY
configuration_schema: config-v3
migration: add-export-state
old_code_can_read_new_schema: yes
verification:
  - authenticated-read
  - enqueue-and-complete-test-export
  - failed-dependency-behavior
rollback_decision: keep-additive-schema-and-previous-artifact
operator_and_result: TO_BE_RECORDED

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

Відокремте підготовку від просування

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

З Compose запущений контейнер не встановлює готовність. Змістовна перевірка працездатності та condition: service_healthy можуть зробити очікування залежності корисним, але не можуть перевірити клієнтський робочий процес. Застосунок усе одно повинен обробляти недоступність залежності після запуску.

Технічна довідка: Порядок запуску Docker Compose.

Перевірте більше, ніж зелений порт

Для API звітності перевірте автентифікований тестовий запит, читання з цільової схеми, один невеликий експорт у черзі та доступ до його файлу. Використовуйте окремий тестовий простір імен і вимкніть сповіщення виробництва. Переконайтеся, що версії, які перекриваються, не можуть випадково дублювати заплановану роботу.

Запишіть очікувані результати перед перевіркою: правильна область облікового запису, очікуваний приклад запису, один завершений експорт і відсутність несанкціонованих даних іншого облікового запису. Запишіть фактичні результати та час після цього. Головна сторінка, що повертає HTTP 200, недостатня, якщо робочий процес постійно зазнає невдачі або міграція залишила API читати застарілі значення.

Зробіть рішення про відновлення явним

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

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

Залиште запис, який інший супровідник зможе відтворити

Порівняйте розгорнутий артефакт та ідентифікатори конфігурації із запланованим записом. Збережіть перевірки, невдалі спроби та обрану дію відновлення. Тримайте останній робочий артефакт відповідно до явної політики зберігання; не видаляйте його, поки перевірка не завершена.

Корисна репетиція дозволяє іншому уповноваженому супровіднику пояснити вхідні дані, повторити перевірки та знайти інструкції з відновлення без пошуку в історії вашої оболонки. Вона не доводить нульовий час простою або майбутній успіх. Поверніться до неї, коли зміняться схема, поведінка робочого процесу або залежності. Далі, звужте дозволи ідентичності розгортання.