ну и раз я давно молчал, то надо бы поделиться...

ну и раз я давно молчал, то надо бы поделиться чем-нибудь полезным!

очень много в последний год было разговоров про гипер-кастомизацию. дескать, теперь можно продукты адаптировать даже под очень небольших клиентов, потому что стоимость доработок копеечная, благодаря ИИ-кодингу. где-то здесь правда висел в воздухе вопрос "а как потом поддерживать 300 версий продукта", но на него тоже был ответ в духе "ИИ справится".

разговоров много, но вот каких-то реализаций в проде я не видел.

пару месяцев назад b2b-клиент пришёл с "а можно фичу", и это была нахер никому не нужная фича кроме него. я хотел сказать "нет", а потом подумал - а чё нет-то? сел думать, как сделать так, чтобы я мог безболезненно поддерживать много таких уникальных хотелок.

изначально пошёл по пути с единой кодовой базой и фича-флагами. этот процесс очень быстро стал болезненным - когда в проекте уже 5+ больших уникальных доделок, при этом они ещё зачастую конфликтуют (2 клиента просят разный вид одного компонента), агенты начинают путаться в коде (какой сценарий дефолтный, а какой "заточка под клиента"), да и выглядит всё жутко грязно. в общем, процесс надо было менять. решил пойти по пути гит-бранчей.

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

• итак, в начале классический гит-флоу:

1. продуктовые фичи разрабатываются в отдельных фича-бранчах (речь о фичах, которые нужны всем, а не об уникальных) 2. dev-ветка как нестабильный предрелизный код. в неё мерджатся фича-бранчи, когда агент делает ревью фича-бранча - он делает именно ревью диффа против dev'а. 3. main-ветка это стабильная версия продукта. после тестирования и фиксов в dev'е, мердж-коммит dev в main это и есть релиз (да, без release/* веток, всем норм)

• дальше начинается самое интересное:

1. под каждого клиента с уникальными хотелками заведена персональная ветка head/hc-[имя клиента]. в этой ветке есть специальная спека PATCH.md, с детальнейшим описанием уникальных фич, сделанных под этого клиента. этот файл - точка входа для агента, который реализует/обновляет эти фичи. это спека как по функциональности, так и по всему процессу тестирования (естественно, полная автоматизация, рук человека тут не должно быть вообще). помимо этого, в этой же ветке AGENTS.md модифицирован - там идёт объяснение агенту, что он находится в спец. ветке, упоминание PATCH.md, требование посмотреть diff текущей ветки над main, чтобы понять, какие уникальные отличия здесь есть (то есть patch.md - описание, diff - реализация).

2. коммит в main триггерит скрипт, который автоматически создаёт pull request из main в каждую head/hc-* ветку (простейший github action).

3. у меня есть локальный workflow (да, я фанат локальных агентов на отдельном макбуке), который замечает эти пулл-реквесты и последовательно для каждого запускает отдельную сессию агента. задача агента - с учётом знаний о том, какие уникальные фичи должны быть на этой ветке, и инфы (diff этой ветки поверх main) о фактической реализации, произвести корректный merge и тестирование. когда создаётся сессия агента, связка "ID пулл реквеста <> ID сессии агента" сохраняется, чтобы все последующие триггеры по этому пулл-реквесту летели в тот же контекст.