Управление релизами и откат изменений

CloudflareBeginner
Практиковаться сейчас

Введение

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

Вы уже должны понимать, как разрабатывать локально с Wrangler, авторизовывать аккаунт и выполнять развёртывание. Начните работу в этой чистой виртуальной машине со своей учебной учётной записью; предыдущая виртуальная машина или Worker не используются повторно. В процессе настройки устанавливаются Node.js 22.22.0 и локальный для проекта Wrangler 4.131.1, а также предоставляются два небольших синтетических обработчика. Домен, сервис хранения данных и секрет не требуются. Все действия по развёртыванию и очистке вы выполняете самостоятельно.

Версия — это сохранённый снимок кода и конфигурации, который не изменяется после создания. Развёртывание выбирает версию, получающую запросы, то есть трафик. Откат создаёт новое развёртывание существующей версии; он не изменяет локальный исходный код и не восстанавливает данные в связанных ресурсах. См. официальный обзор версий.

Подготовка заведомо рабочего релиза

На этом шаге подготовьте заведомо рабочую точку входа и проверьте её поведение локально. Предоставленные файлы позволяют сосредоточиться на операциях с релизами. Рабочий обработчик возвращает available=true; неисправный сохраняет работоспособность, но возвращает 503 для бизнес-маршрута.

cd /home/labex/project/release-recovery
cat versions/good.js
diff -u versions/good.js versions/faulty.js

Команда diff завершится с кодом 1, потому что файлы различаются; это ожидаемый результат. Изменяются только доступность и соответствующий статус HTTP. Копирование рабочего файла выбирает исходный файл, указанный в конфигурации.

cp versions/good.js src/index.js

Сгенерируйте уникальное имя с помощью стандартного API crypto в Node. В приведённой ниже команде разделитель EOF не заключён в кавычки, поэтому переменная оболочки подставляется в JSON. Файл не содержит комментариев, поэтому его также можно анализировать стандартными средствами работы с JSON.

WORKER_NAME="labex-release-$(node -p "require('node:crypto').randomBytes(6).toString('hex')")"
cat > wrangler.jsonc <<EOF
{
  "name": "$WORKER_NAME",
  "main": "src/index.js",
  "compatibility_date": "2026-07-30",
  "workers_dev": true,
  "preview_urls": false,
  "version_metadata": {"binding": "RELEASE"}
}
EOF

Метаданные описывают выполняемый код, а не его бизнес-данные. Привязка метаданных версии предоставляет идентификатор и тег версии во время выполнения, позволяя определить, какой релиз сформировал ответ, вместо того чтобы делать выводы только по его поведению. Локальная разработка использует локальные метаданные; только метаданные развёрнутого Worker идентифицируют версию в облаке. Описание этой привязки доступно здесь.

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

npx wrangler dev --ip 0.0.0.0 --port 8080 > dev.log 2>&1 &
cat dev.log
curl -i http://127.0.0.1:8080/health
curl -i http://127.0.0.1:8080/api/availability

Оба маршрута должны вернуть 200; значение availability должно быть true. Локальные значения версии и тега могут быть заполнителями, используемыми в режиме разработки. Перед остановкой процесса разработки на следующем шаге выполните проверку.

Развёртывание и сохранение рабочей версии

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

jobs
kill %1
npx wrangler login --device --browser=false --scopes account:read user:read workers_scripts:write workers_tail:read

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

npx wrangler whoami --json

Замените YOUR_ACCOUNT_ID ниже фактическим идентификатором этого аккаунта. Эта стандартная команда Node изменяет явную конфигурацию проекта; аккаунт не выбирается с помощью временной переменной окружения.

node -e 'const fs=require("node:fs");const p="wrangler.jsonc";const c=JSON.parse(fs.readFileSync(p));c.account_id="YOUR_ACCOUNT_ID";fs.writeFileSync(p,JSON.stringify(c,null,2)+"\n");'
cat wrangler.jsonc

Тег — это понятная человеку метка, а UUID версии — точный идентификатор. При развёртывании загружается версия, и на неё направляется трафик. Сообщение описывает назначение версии.

npx wrangler deploy --tag good --message "Known-good availability"

Скопируйте выведенные URL workers.dev и Current Version ID в следующие команды. Это примеры-заполнители, а не фиксированные общие ресурсы. Если для этого аккаунта ещё не настроен поддомен workers.dev, выполните начальную настройку из раздела «Deploy Your First Cloudflare Worker», затем повторите развёртывание.

APP_URL="https://YOUR_WORKER.YOUR_SUBDOMAIN.workers.dev"
printf '%s\n' "YOUR_GOOD_VERSION_ID" > good-version.txt
curl -i "$APP_URL/api/availability"
npx wrangler deployments status
npx wrangler versions list

Ожидайте статус 200, значение available=true, тег good и сохранённый UUID версии в ответе. Активное развёртывание должно направлять на эту версию 100% трафика. Откройте именно этот Worker в Dashboard и просмотрите раздел Deployments, чтобы сопоставить версию из CLI и активное развёртывание с отображаемым ресурсом. Если сразу после развёртывания ответ всё ещё показывает предыдущее состояние, подождите пять секунд и повторяйте чтение не более одной минуты; не изменяйте код, чтобы скрыть задержку распространения. Выполните проверку после того, как результаты наблюдений совпадут.

Наблюдение за неисправным релизом

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

cp versions/faulty.js src/index.js
npx wrangler deploy --tag faulty --message "Demonstrate availability regression"

Сохраните новый Current Version ID этого развёртывания, а не идентификатор рабочей версии. Проверьте оба маршрута и текущее развёртывание.

printf '%s\n' "YOUR_FAULTY_VERSION_ID" > faulty-version.txt
curl -i "$APP_URL/health"
curl -i "$APP_URL/api/availability"
npx wrangler deployments status
npx wrangler versions list

Проверка работоспособности по-прежнему возвращает 200. Доступность теперь возвращает 503, available=false и тег faulty. UUID во время выполнения должен совпадать с новым активным UUID версии, на которую направлено 100% трафика. Ошибка 503 — это предусмотренный дефект данного шага, а не причина пропускать проверку. Если распространение изменений ещё не завершилось, выполните такую же ограниченную по времени повторную проверку ответа. Для независимой проверки необходимо, чтобы неисправность была наблюдаема до восстановления.

В разделе Compute → Workers & Pages откройте именно свой Worker и выберите Deployments. Сравните идентификатор в разделе Active deployment со строкой с тегом faulty в Version History. На снимке экрана используются сокращённые демонстрационные UUID; в командах применяйте сохранённые полные UUID. Рабочая версия остаётся в истории, даже пока активна неисправная версия. Используйте приведённую выше команду wrangler deployments status, чтобы подтвердить настроенное распределение 100% трафика; нулевые показатели активности на этом спокойном снимке экрана не доказывают работоспособность бизнес-маршрута.

Неисправная версия активна, а заведомо рабочая версия остаётся в истории

Откат и синхронизация локального исходного кода

На этом шаге восстановите точную заведомо рабочую версию. Версия — это сохранённый снимок приложения, а развёртывание выбирает версию, получающую трафик. Откат изменяет этот выбор, поэтому для восстановления можно повторно использовать версию, уже сохранённую в Cloudflare. Прочитайте сохранённые идентификаторы и проверьте рабочую версию перед изменением направления трафика. Подстановка команды оболочки считывает её UUID из файла; новая версия при этом не загружается.

cat good-version.txt faulty-version.txt
npx wrangler versions view "$(cat good-version.txt)"

Подтвердите рабочий тег, нужные Worker и аккаунт, а также UUID. Откат направит 100% трафика этого временного Worker на эту версию. Сообщение фиксирует причину восстановления. Выполняйте команду только после проверки цели.

npx wrangler rollback "$(cat good-version.txt)" --message "Restore known-good availability"

Когда Wrangler запросит необязательное сообщение, нажмите Enter, чтобы принять Restore known-good availability. Прочитайте отображаемые рабочий UUID и цель с 100% трафика; в соответствующем запросе подтверждения нажмите одну клавишу y. Прежде чем продолжить, дождитесь сообщения об успешном откате.

npx wrangler deployments status
curl -i "$APP_URL/api/availability"

Новое развёртывание должно использовать исходный UUID рабочей версии; его идентификатор развёртывания не обязан совпадать с исходным. Доступность снова возвращает 200 и true. Обновите вкладку Deployments в Dashboard и сравните активный UUID. При необходимости выполните такую же ограниченную одной минутой повторную проверку ответа.

В этом примере Active deployment снова имеет сокращённый идентификатор 7afe5d31 — тот же, что был у исходной версии good. Маркер активности в Version History переместился на эту строку, а неисправная версия по-прежнему отображается. Сопоставьте эти связи со своими идентификаторами; не копируйте значения из примера. Эта страница показывает выбранную версию, а ответ availability подтверждает восстановление поведения.

Исходная рабочая версия снова активна после отката, а неисправная версия сохранена в истории

Откат не изменяет локальный исходный код. Восстановите рабочий файл локально, чтобы последующее обычное развёртывание случайно не вернуло известную неисправность. Режим dry-run собирает пакет из локального исходного кода, но не загружает его.

cp versions/good.js src/index.js
npx wrangler deploy --dry-run

Выполните проверку: она сравнивает реальный UUID и тег во время выполнения с текущим развёртыванием, которому назначено 100% трафика, и проверяет, что предыдущее неисправное развёртывание остаётся в истории. Локально созданного файла с признаком успеха недостаточно.

Откат не отменяет записи в базу данных, очередь или внешний API, а изменения связанных ресурсов могут сделать старые версии несовместимыми. В этой лабораторной работе таких ресурсов нет. В реальном инциденте оцените эти границы перед восстановлением. В документации по откату описаны ограничения и период хранения версий.

Удаление тестового Worker для релиза

На этом шаге удалите временный Worker, пока авторизация ещё действует. Перед удалением подтвердите его точное имя и аккаунт.

cat wrangler.jsonc
npx wrangler delete

В запросе с совпадающим именем нажмите одну клавишу y. Закреплённая версия Wrangler может сообщить об ошибке аутентификации при очистке устаревшего KV после удаления Worker. Не предоставляйте более широкие разрешения и не считайте любую ошибку доказательством удаления. Обновите Dashboard и выполните проверку: успешная аутентифицированная инвентаризация должна показать, что этого Worker нет. Не затрагивайте учебную учётную запись, поддомен и несвязанные ресурсы.

Отключение виртуальной машины

На этом шаге отключите виртуальную машину после успешного удаления. Один только выход из аккаунта не удалит развёрнутый Worker.

npx wrangler logout
npx wrangler whoami --json

Ожидайте loggedIn=false; структурированная команда может завершиться с ненулевым кодом, поскольку теперь вы не авторизованы. Выполните финальную проверку. Вход в браузере и учебная учётная запись останутся доступными для будущих независимых лабораторных работ.

Итоги

Вы сравнили версии Worker с активными развёртываниями, наблюдали регрессию бизнес-маршрута при исправной проверке liveness и восстановили выбранную рабочую версию. Метаданные во время выполнения связали фактические ответы с развёртыванием, которому назначено 100% трафика. Вы также восстановили локальный исходный код, проверили очистку в облаке и отключили виртуальную машину.