After RTM: что пошло не идеально и почему это нормально

30, Декабрь 2025

RTM-релиз From the Basement для dCMS Pheix прошёл спокойно, без аварий и откатов. Система стабильно работает в production, данные сохраняются, транзакции уходят в блокчейн, пользователи ничего не заметили.

Но если быть честным — релиз не был идеальным. И это нормально.

Я хочу зафиксировать несколько моментов, которые проявились после релиза. Не как список оправданий, а как инженерный журнал — потому что именно в таких деталях система по-настоящему взрослеет.

1. Сломанный юнит-тест в релизном архиве

На первый взгляд проблема выглядела банально: в релизном архиве dCMS Pheix оказался юнит-тест, который не проходит. Но за этим скрывалась довольно показательная история про границы автоматизации и реальные данные.

Важно понимать архитектурный контекст. Дистрибутив dCMS Pheix состоит из трёх независимых компонентов, размещённых в разных репозиториях:

• исходный код системы;
• конфигурационные файлы;
• web-assets (шаблоны, JS, CSS, media).

В репозитории конфигурации, помимо настроек, хранятся и файлы контента веб-сайта системы. В том числе — контент официального сайта dCMS Pheix, который сам работает под управлением Pheix.

К моменту релиза анонс From the Basement был опубликован прямо в блокчейне Ethereum — в тестовой сети Hoodi:

• непосредственно в основной цепочке блоков;
• в Beacon chain в виде blob’а.

Это два разных файла контента, потому что в тексте есть динамические подстановки: номер блока, хэш транзакции, номер слота и хэш blob’а. Соответственно, в конфигурации появились ссылки на два разных ончейн-источника.

И вот здесь начинается самое интересное. До обновления конфигурации все тесты проходили успешно. Но сразу после того, как в конфиге появились ссылки на данные из основной цепочки Hoodi и Beacon chain, один из базовых юнит-тестов начал падать.

Причина оказалась в логике тестирования. Базовые юнит-тесты dCMS Pheix частично проверяют данные, размещённые в блокчейне. Если в конфигурации присутствует ссылка на ончейн-контент, тесты дополнительно выполняют проверку целостности: они буквально сравнивают данные, полученные из блокчейна, с локальными файлами контента — на побайтовую идентичность.

И тут всплыл важный нюанс: данные, извлечённые из blob’ов, минимально нормализованы. В процессе оптимизации объёма хранения в них вычищаются лишние пробелы, переносы строк и табуляции.

С точки зрения системы — это эквивалентные данные. С точки зрения юнит-теста — это уже не идентичный эталон. Для таких случаев в системе тестирования предусмотрен список исключений: идентификаторы ончейн-страниц, для которых строгая проверка отключается. И вот здесь была допущена человеческая ошибка.

Контент, размещённый в нативном чейне Hoodi, в этом списке был. А blob-контент из Beacon chain — нет. В результате тест честно делал ровно то, для чего был написан, — и честно падал. Это не дефект системы и не проблема пользователей. Это пример того, как реальные ончейн-данные выходят за рамки лабораторных предположений, и система тестирования требует ручной настройки даже в RTM.

Хороший урок и напоминание: автоматизация не отменяет инженерного внимания, особенно когда код начинает работать с живым блокчейном.

2. Сжатый и зашифрованный blob-контент

Вторая проблема была уже ближе к ядру системы.

Оказалось, что dCMS Pheix корректно работает с plain-blob контентом, но ломается на отображении сжатого и зашифрованного blob’а. Данные не терялись, транзакции проходили, но слой отображения падал.

Это классический случай, когда happy-path покрыт, а composition-path — нет: blob → compression → encryption → decode → render → 😢.

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

Это не признак слабости RTM, а признак того, что система уже достаточно сложна, чтобы такие кейсы начали проявляться.

3. Версии, merge и честная верификация

Третий пункт — самый ценный.

До релиза логика верификации версий корректно работала только при линейном обновлении: 0.0.1 → 0.0.2.

Но при merge версия не меняется — и система начинала вести себя неестественно. Приходилось использовать костыли, чтобы обходить проверки. Формально всё работало. Архитектурно — нет.

Откровенно говоря, проблема была известна давно, но после RTM стало очевидно, что само предположение о том, что версия всегда должна меняться, стоит пересмотреть. Merge — это другая семантика, и система должна это понимать.

Логика наконец была исправлена. Не потому что «сломалось», а потому что стало окончательно понятно, как верификация версий должна работать правильно.

4. Выводы

Если собрать всё вместе, получается важная картина:

• не было падений production;
• не было потери данных;
• не было архитектурного коллапса.

Зато были:

• шероховатости процесса;
• сложный edge-case;
• архитектурное уточнение после релиза.

Именно так выглядит первый настоящий RTM живой системы, а не демо-проекта.

5. RTM — это не финал

From the Basement — это момент выхода из подвала, но не конец пути. Это точка, после которой система начинает жить под реальной нагрузкой, в реальном мире, с реальными обновлениями блокчейна и реальными ошибками.

Я намеренно фиксирую эти моменты публично — потому что зрелость проекта определяется не отсутствием ошибок, а тем, как с ними работают.

Продолжаем 🚀🚀🚀