Это форма доставки софта: самая зрелая команда, которую водит Forge, построенная на движке процессов Forge . Это одна форма из нескольких — та же механика ведёт команды исследований, контента и эксплуатации. Здесь она разобрана подробно; остальные см. в работах, которые команды передают целиком .
Как это работает
Вы ставите на задачу в GitHub метку forge-pipeline. Forge открывает по этой задаче рабочую сессию и запускает первую роль. Каждая роль делает законченный кусок работы: читает то, что ей передали, пользуется разрешёнными ей инструментами и заканчивает выжимкой для того, кто идёт следующим.
Что делает каждая роль
Продакт-менеджер — читает задачу. Если формулировка неоднозначна, задаёт вам вопрос, а не угадывает. Выдаёт явный список того, что означает «готово», и разбивает крупную задачу на независимые куски, которые можно делать параллельно.
Архитектор — берёт этот список и решает, как подступиться: что где лежит, какие контракты меняются, как выглядят данные. Ссылается на настоящие файлы вашего репозитория, а не описывает абстрактный дизайн.
Разработчик — делает. Код, тесты и, если нужно, миграция — коммитами в ветку, которая принадлежит этому прогону.
Тестировщик — прогоняет тесты. Проходит по критериям приёмки, которые написал продакт-менеджер. Внимательно смотрит на всё, что значимо для безопасности. Сообщает результат с логами, которые можно воспроизвести.
Ревьюер — сверяет дифф с исходными критериями и решения архитектора. Комментирует, возвращает на доработку или подтверждает. При подтверждении открывает pull request, который сливает человек.
Что передают друг другу
Роль не отдаёт следующей свою стенограмму на перечитывание. Она передаёт короткую структурированную выжимку: каков объём, каковы критерии приёмки, какие решения приняты и почему. Следующая роль стартует с неё.
Здесь важнее формата две вещи.
Выжимку читают до того, как доставить. Между каждой парой ролей стоит управляющий агент и решает, достаточно ли передача хороша, чтобы пустить её дальше. Он может вернуть работу с конкретными указаниями или позвать человека. Именно этого одиночный агент не может структурно: агент, проверяющий сам себя, делит с собой же и все допущения.
Механика не ломается от сбоя. Если модель выдала что-то, из чего выжимку извлечь не получилось, прогон не встаёт: следующая роль просто получает сырой диалог как контекст и продолжает. Структура — преимущество, когда она есть, а не условие, без которого прогон не доедет.
Разговор с командой посреди прогона
Пока прогон идёт, каждый ваш комментарий к задаче — а позже к pull request — попадает к той роли, которая работает прямо сейчас. Forge находит живую сессию, добавляет комментарий в неё и даёт этой роли ещё один ход. Цепочка не начинается заново.
Так что можно попросить продакт-менеджера уточнить требование, сказать разработчику взять другую библиотеку или оспорить покрытие у тестировщика — всё со страницы задачи. Она работает как консоль прогона.
Поменять состав
Пять ролей — это умолчание, а не данность. Роли можно выключать, переставлять местами и заменять своими, отдельно для каждой организации, — см. Свои роли . Чаще всего на мелких изменениях убирают архитектора или добавляют ревьюера по безопасности перед ревьюером кода.
Что вы получаете
Всё перечисленное уже работает в продакшене.
- Метка на задаче как точка входа: прогон привязан к этой задаче на всю свою жизнь
- Пять ролей по порядку, и каждую передачу читают и оценивают, прежде чем пустить дальше
- Ваши комментарии попадают к работающей сейчас роли — и на задачах, и на pull request
- Pull request с полным следом того, как работа к нему пришла
- Круги ревью и правок: ревьюер возвращает работу разработчику, число кругов ограничено
- Агенты-персонажи — названные персонажи со своей памятью о вашей организации
- Режим соревнования — две команды на одном брифе, когда подход действительно неочевиден
- Собственные роли, заданные для вашей организации
- Атрибуция по каждому ходу: какая машина что выполнила, видно в интерфейсе
- Редактор умолчаний по ролям для вашей организации
Прежде чем любое изменение самого Forge уедет в прод, вся цепочка из пяти ролей обязана проехать от задачи до pull request автотестом — и режим соревнования тоже. Мы держим на этом собственные релизы.
Попробовать
- Установите GitHub App Forge на свой репозиторий.
- Заведите любую задачу и поставьте метку
forge-pipeline. - Следите за комментариями — каждая роль объявляет себя и пишет о ходе работы.
- Отревьюйте pull request, когда он появится, и слейте его сами.