Переименование сайта без потери данных

Клиент просит переименовать сайт с acme-staging на acme. Вы меняете имя в приложении. Внезапно все резервные копии базы данных, скриншоты и миниатюры исчезают.

Файлы всё еще существуют на диске. Новая директория просто пуста. Данные не переместились вместе с изменением имени.

Мы допустили эту ошибку в нашей первоначальной архитектуре. Мы использовали имя сайта для определения места хранения файлов.

Если вы храните файлы в backups/acme-staging/, а затем переименовываете сайт в acme, приложение ищет их в backups/acme/. Оно находит пустую папку. Старые данные остаются в старой папке, но приложение считает их устаревшими данными другого сайта.

Имена сайтов меняются часто. Клиенты исправляют опечатки. Команды переносят стейджинг-сайты в продакшн. Компании проводят реорганизацию.

Мы исправили это, отделив отображаемое имя от стабильного идентификатора.

Теперь у каждого сайта есть уникальный ID. Он выглядит как site_a1b2c3d4e5f6. Этот ID никогда не меняется.

Теперь мы храним файлы, используя ID вместо имени. Путь к директории выглядит как backups/site_a1b2c3d4e5f6/. Даже если вы переименуете сайт, путь останется прежним. Данные остаются связанными.

Самым сложным было перевести существующих пользователей на эту систему. Мы создали идемпотентную миграцию. Это означает, что при запуске система проверяет наличие ID. Если у сайта нет ID, система присваивает его. Если он есть, система его не трогает.

Мы также перенесли физические файлы. Если система находит папку, названную именем сайта, она переименовывает её в новый формат ID.

Мы даже исправили логи. В новых логах используется ID. В старых логах используется имя сайта. Интерфейс объединяет оба варианта, чтобы история выглядела непрерывной.

Мы извлекли суровый урок о валидации. После обновления мы добавили правило для проверки форматов ID. Правило оказалось слишком строгим. Оно отклонило некоторые старые ID из нашей миграции. Внезапно сайты снова исчезли.

Урок прост: проверяйте свои данные перед добавлением новых правил.

Отделение того, что видят люди, от того, что использует система — это классический паттерн. Делать это после запуска дорого и рискованно. Используйте неизменяемые ID с первого дня, чтобы избежать этой ловушки.

Источник: https://dev.to/susumun/renaming-a-site-without-losing-its-data-separating-display-name-from-a-stable-identifier-gpb