Год без изменений — а потом одна правка всё сломала
Ситуация
Сервис для внутреннего учёта у клиента был сгенерирован год назад, выпущен в продакшен — и с тех пор жил без единого обновления. Продукт был успешным в узком смысле: он работал, люди им пользовались, все привыкли. Но за год бизнес-процессы чуть изменились, и потребовалась одна небольшая правка в отчётной форме.
Владелец, вдохновлённый тем, как легко всё получилось год назад, попробовал внести изменение тем же способом — через тот же ИИ-инструмент. Правка внешне выглядела разумной. Но после неё сборка перестала собираться: несовместимые версии зависимостей, сломанная конфигурация окружения, ошибки, которые ИИ на новой итерации уже не смог сам объяснить, потому что не видел исходного контекста создания проекта. Откатиться назад тоже не вышло — версии, с которой всё работало, в git не было, только то, что оставалось задеплоенным на сервере. Старая версия продолжала крутиться в проде без новой функциональности, а новую собрать не получалось уже несколько недель. Владелец решил, что дешевле смириться и продолжать работать по-старому.
Диагноз
Ситуация внешне выглядела как «всё пропало», но технически — стандартная поломка окружения, просто без единой точки, с которой можно было бы начать. Первым делом снял полный слепок того, что реально работает в проде: версии рантайма, переменные окружения, конфигурацию сервера, зависимости — то, чего не было в исходниках, потому что раньше это никого не заботило.
Дальше — построчное сравнение рабочей и сломанной версий кода. Оказалось, что «небольшая правка» неявно потянула за собой обновление мажорной версии одной библиотеки, которая изменила формат конфигурации. ИИ на новой итерации честно исправлял симптомы, не видя, что причина в одной строке импорта тремя уровнями выше.
Что сделали
- Зафиксировал рабочую версию из продакшена как первый коммит в репозитории — прод перестал быть единственным источником истины.
- Локализовал причину поломки сборки, откатил проблемную зависимость до совместимой версии, внёс саму нужную правку в отчётной форме уже отдельным, изолированным изменением.
- Настроил минимальный CI: сборка на каждый коммит, чтобы поломка окружения обнаруживалась за минуту, а не спустя недели простоя.
- Составил короткий регламент для владельца: что можно менять самостоятельно через ИИ-инструменты, а что стоит сначала показать технической стороне — не чтобы ограничить, а чтобы новая правка не повторила ту же историю.
Результат
Новая версия собралась и уехала в прод впервые за год простоя. Владелец получил не только нужную фичу, но и git-историю, CI и понятную границу «что я могу поправить сам, а с чем лучше не рисковать в одиночку». Самое ценное здесь — не код, а восстановленная надежда: за несколько недель до обращения ко мне клиент был готов свернуть проект и переходить на готовое коробочное решение, потеряв год данных и привычек команды.
У вас такая же ситуация?
Давай решим...