Переключение задач через снапшоты

Вы в разгаре работы над фичей: миграции накатаны наполовину, тестовые данные засеяны — и тут на main прилетает хотфикс. Нужен чистый стек, чтобы воспроизвести баг, пофиксить его и вернуться ровно туда, где вы были: те же строки в БД, тот же индекс поиска, тот же local.yml. Это руководство — сборник рецептов для такого сценария.

Снапшоты — это механизм контрольных точек DWE. Они захватывают изменяемые данные проекта (БД, поисковые индексы, журнал деплоя, workspace/local.yml) в именованный каталог ./snapshots/<имя>/ и позволяют восстановить их позже как мягкую операцию — без reset, без пересоздания контейнеров, без повторного прогона деплоя.

Шаблон `baseline`

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

baseline — заведомо рабочее, почти пустое состояние, в которое всегда можно откатиться (чистые seed-данные, никаких незавершённых миграций).
wip-<branch> — контрольная точка под конкретную задачу, которую вы создаёте, когда нужно переключиться с незавершённой работы.

baseline — это просто обычное имя снапшота. Ничего зарезервированного в нём нет — соглашение окупается тем, что любое другое руководство и любая привычка могут однозначно ссылаться на «восстановить baseline».

Создайте один раз, сразу после чистого деплоя:

dwe snapshot create baseline -d "чистое состояние после деплоя"

Полный цикл «фича на паузе из-за хотфикса»

# 1. сохраняем контрольную точку незавершённой работы по фиче
dwe snapshot create wip-feature-x -d "WIP: фича X, миграции применены"

# 2. чистый старт под хотфикс
dwe snapshot restore baseline

# 3. ... воспроизвести, пофиксить, запушить, смерджить хотфикс ...

# 4. вернуться туда, где были
dwe snapshot restore wip-feature-x

Restore — это по конвенции drop + restore: проектная команда db.restore обычно дропает целевую базу и перезаливает её из ${snapshot.path}/db/main.sql.gz. Контейнеры не пересоздаются, шаги деплоя не выполняются — меняются только данные и файлы workspace.

workspace/local.yml входит в снапшот, но всё, объявленное под local_yml.preserve_keys в workspace/snapshot.yml (порты, хосты, пути — см. write-snapshot-workflows.md), вшивается обратно из вашей текущей копии, так что машинно-локальные оверрайды переживают свап.

Откат одной командой через `rollback_target`

Если вы часто переключаетесь на baseline (или другой «безопасный» снапшот), объявите его как rollback-цель в workspace/snapshot.yml:

rollback_target: baseline

Тогда dwe snapshot rollback — это шорткат для dwe snapshot restore baseline — полезно в мышечной памяти и в скриптах. Команда явно падает, если целевого снапшота нет. Справочник: ../reference/config/snapshot.md.

Изучение того, что есть

dwe snapshot list                  # всё под ./snapshots/
dwe snapshot current               # что создано или восстановлено последним
dwe snapshot inspect wip-feature-x # содержимое манифеста: описание, артефакты, набор сервисов, config_hash

inspect — это то, к чему обращаются, когда не уверены, что снапшот ещё актуален: он показывает зафиксированный набор сервисов, config_hash на момент создания, размеры и sha256 каждого артефакта.

Передача снапшота коллеге

Снапшоты — локальные файлы, но они аккуратно пакуются и распаковываются:

# производитель
dwe snapshot pack wip-feature-x
# → ./snapshots/wip-feature-x.tar.gz

# потребитель
dwe snapshot unpack ./snapshots/wip-feature-x.tar.gz
dwe snapshot restore wip-feature-x

pack пишет один .tar.gz (без отдельного файла с контрольной суммой). unpack сверяет каждый артефакт архива с записанным в манифесте sha256, прежде чем переместить дерево в ./snapshots/. Если что-то не прошло проверку — перед тем как снапшот ляжет, появится запрос подтверждения; отказ оставляет рабочее дерево нетронутым.

Когда эффективный набор сервисов получателя расходится с набором, записанным в снапшоте, restore поднимает диф через политику services_mismatch (warn по умолчанию, можно поднять до block в workspace/snapshot.yml). Справочник: ../reference/config/snapshot.md.

Что снапшот НЕ делает

Стоит проговорить явно, потому что каждый из этих пунктов хотя бы раз кого-то кусает:

Не пересоздаёт контейнеры. Restore меняет файлы данных и конфиг workspace; работающие контейнеры продолжают работать с тем образом и конфигом, с которыми были подняты. Если снапшот делался на другом теге образа, работающий контейнер теперь выполняет устаревший код на новых данных.
Не повторяет деплой. .dwe/deploy/state.yml перезаписывается зафиксированным журналом снапшота, но описанные в нём шаги не выполняются заново. Если снапшот сделан до того, как в workspace/deploy.yml появился новый шаг — на restore этот шаг не запустится; запустит его dwe deploy при следующем вызове.
Не делает reset. Volumes, untracked-файлы в дереве проекта и всё за пределами артефактов, которые ваш create: явно захватил, не трогаются. Restore аддитивен поверх того, что сейчас на диске.
Никакой магии на уровне данных. Ядро снапшота не знает, что такое база. Ваши create: и restore: вызывают ваши же команды db.dump / db.restore; если они дропают и перезаливают — restore дропает и перезаливает. Если аппендят — restore аппендит.

Когда нужна по-настоящему чистая база, для этого есть dwe reset run — см. troubleshooting.md. Распространённый шаблон — snapshot create pre-reset непосредственно перед reset run, чтобы был откат, если reset окажется агрессивнее ожидаемого.

Что дальше

write-snapshot-workflows.md — авторство собственного snapshot.yml: воркфлоу create / restore / remove, варианты, шаблон ${snapshot.path}, preserve_keys, политика services_mismatch.
../reference/config/snapshot.md — полная схема справочника.