Тимур Городецкий
58a6e13f36
Один разработчик без ревью: ветка нужна не всегда, а когда защищает main от полуготового кода. Мелкие фиксы — прямо в main. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2.9 KiB
2.9 KiB
Как ведётся работа над порталом
Проект ведёт один разработчик. Требования приходят из Teams-чата и устно, поэтому вся история — что просили, что решили, что выехало — хранится здесь и в Gitea, а не в памяти.
Где что лежит
| Что | Где | Отвечает на вопрос |
|---|---|---|
| Задачи | Gitea Issues ct-forms-portal |
Что надо сделать, кто и когда попросил |
| Решения | docs/adr/ |
Почему сделано именно так, какие были варианты |
| Изменения | CHANGELOG.md |
Что и в какой версии выехало на прод |
| Код | коммиты с (#номер) |
Каким кодом закрыта задача |
Путь запроса
- Пришло сообщение (чат, устно) — каждый пункт становится issue. В issue — цитата или скрин как есть, дата, кто попросил.
- Разбор. Метка по типу:
bug,ux,feature,perf,справочники,вопрос-бизнесу,смена-модели.- Если пункт меняет устройство данных (
смена-модели) — сначала ADR, потом код. - Если нужен ответ бизнеса (
вопрос-бизнесу) — вопрос в чат, issue ждёт ответа.
- Если пункт меняет устройство данных (
- Работа. Баг — сначала падающий Jest-тест, потом фикс. Коммиты —
тип: описание (#номер).- Мелкий фикс (час-два, один-два коммита) — прямо в
main. - Ветка
feat/<номер>-краткоилиfix/<номер>-кратко— если задача на несколько дней, зависит от внешнего (новые списки SP, потоки, бэкенд) или рискованная. Цель одна:mainв любой момент можно выкатить на прод.
- Мелкий фикс (час-два, один-два коммита) — прямо в
- Деплой. Запись в
CHANGELOG.md, тег версииvX.Y.Z(= версия вconfig/package-solution.json), issue закрывается, в чат — короткий список изменений.
Вопрос, который задаём каждому новому пункту
Это меняет то, как устроены данные, или только как они показываются?
Только показ или поведение — делаем. Меняет данные — сначала проходим весь путь: где создаётся, кто видит, что уходит в отчёт, INCORE и согласование. Потом ADR.