Перейти к основному содержимому

Rollback

Починено 27.07.2026

Раньше layero rollback печатал rolled back to <sha>, но двигал только environments.active_deploy_id — а публичный адрес резолвится через projects.production_deploy_id. Команда рапортовала об успехе, не восстановив ничего, причём ровно в тот момент, когда прод уже лежал.

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

Откат чужой ветки апекс по-прежнему не трогает: если владелец сознательно держит production на другой ветке, это его выбор.

Пока не работает для runtime-приложений

Откат доступен только проектам со статикой. Если проект работает как runtime-приложение — SSR на Next, Streamlit, Gradio, — layero rollback покажет план и завершится ошибкой: артефакт такого деплоя лежит не в Object Storage, а в реестре образов, а проверка на стороне API требует именно хранилище. На 28.07.2026 это 113 проектов из 507.

Путь назад для них — пересобрать нужный коммит обычным layero deploy с тем кодом. Точечный promote на старый деплой для runtime-проектов использовать не стоит: образ старого деплоя мог быть уже вычищен, и тогда адрес перестанет открываться.

Как откатить​

layero rollback              # вернуться на предыдущий успешный деплой
layero rollback --yes        # без подтверждения

Команда покажет план и, после подтверждения, вернёт и активный деплой окружения, и — если апекс обслуживается этой веткой — публичный адрес.

Когда нужен promote вместо отката​

Если возвращаться надо не на предыдущий деплой, а на конкретный старый — точечно, по commit_sha:

layero deploys list                 # найти commit_sha рабочего билда
layero promote ff0d1b86 --yes       # вернуть апекс на него

Аргумент позиционный. Флага --deploy= не существует, команды layero promote --rollback тоже нет — CLI отвечает unknown option.

promote ищет по commit_sha, а не по id деплоя: promote <deploy-id> даст no deploy matching ….

Почему не пересобрать нужный коммит​

Пересборка предыдущего коммита из git-истории не идемпотентна: npm install против сегодняшнего реестра может дать другой node_modules — lockfile drift, transitive republish. promote берёт тот же артефакт, который работал раньше: он уже лежит в S3 и не пересобирается.

Что происходит при promote на старый деплой​

  1. CLI показывает план и просит подтверждения: 
    promote plan:
      from: ce70191  2026-05-19 07:09  feature: new pricing page (current production)
      to:   1743a29  2026-05-08 20:30  v2.4.0 — stable release
    proceed? [y/N]
  2. Бэкенд атомарно обновляет projects.production_deploy_id, а прошлое значение забирает в previous_production_deploy_id; пишет promote_events (кто, когда, source); инвалидирует resolver-кеш через Postgres NOTIFY.
  3. Через несколько секунд апекс отдаёт нужную версию — задержку даёт только короткий кеш на edge, до минуты.

Два указателя на проекте​

projects.production_deploy_id           ── что апекс отдаёт прямо сейчас
projects.previous_production_deploy_id  ── что отдавал до прошлого promote

previous_production_deploy_id обновляется при каждом promote (UI / CLI / auto-promote), поэтому предыдущий рабочий деплой всегда видно в истории промоутов: Project → Deploys → «Promote history».

Ограничения​

  • Promote возможен только на ready-деплой с артефактом в хранилище (или зарегистрированным runtime-контейнером).
  • Двигается production apex проекта; preview-URL веток не затрагиваются — у каждой ветки своя независимая история деплоев.
  • Для runtime-проектов (SSR Next, Streamlit, Gradio, Flask) указатель переключается моментально, но запущенный инстанс старого билда продолжает отвечать, пока его не дёрнут: cold-start на следующем запросе уже возьмёт нужный артефакт.
  • Если включён auto-promote default-ветки, следующий push в неё перетрёт ручной promote. Выключите его в настройках проекта, если нужен ручной контроль над production.

Альтернативы​

  • В дашборде: страница проекта → карточка Production → кнопка «Откатить». Она работает на стороне бэкенда и двигает production-указатель.
  • Кнопка «Откатить активный деплой» в списке деплоев ведёт себя так же: с 27.07.2026 она тоже возвращает апекс, если публичный адрес обслуживается этой веткой.
  • Если нужен именно пересбор старого коммита, а не переиспользование артефакта — обычный layero deploy с тем кодом или Redeploy в дашборде.

Откуда взялось расхождение​

Раньше у каждой ветки был свой канонический хост, и layero rollback менял environments.active_deploy_id — то есть работал по-веточно. С переходом на модель «один апекс на проект» (V071) откат должен двигать production-указатель проекта. CLI-команда за этой сменой не пошла: она осталась на старом, по-веточном пути. Отсюда и рапорт об успехе при неизменившемся апексе.

Связано: layero promote, Окружения, preview и production.