Представим, что «Команда А» использует программу, написанную «Командой Б». «Команда А» отправляет запрос на новый функционал «Команде Б», однако «Команда Б» не способна вовремя сделать необходимое для первой команды. При работе в InnerSource, если «Команда А» не может получить функционал просто отправив запрос, то она может сама написать код за вторую команду и отправить решение на код-ревью. Другими словами, «Команда А» сама реализует необходимый функционал в репозитории «Команды Б» и отправляет Pull Request с изменениями в коде. «Команда Б» просматривает изменения и в случае, если с ними всё хорошо, принимает отправленный код.
В этом примере, назовём «Команду А» — гостевой командой, а «Команду Б» — хостом или хозяином продукта. Термины гость и хост предпологают ситуацию, аналогичную приёму гостей в доме. Как правило, большинство людей старается быть хорошим хозяином и следят за тем, чтобы дома была чистота и порядок, особенно когда готовятся к приёму гостей. При входе посетителей приветствуют и проводят внутрь. Гости могут использовать все предметы и устройства, доступные публично. Кроме этого, в доме могут существовать правила, соблюдать которые просят всех гостей. Большинство гостей стремятся выражать уважение к хозяевам и их жилищу. Они аккуратно относятся к домовому имуществу и следуют правилам на протяжении всего присутствия. Они ожидают, что если они будут хорошо себя вести, то их позовут снова. Эта аналогия с посещением дома метафорически показывает, как команды должны взаимодействовать между собой, когда одна команда отправляет гостевой код хозяевам репозитория.
Теперь рассмотрим механику InnerSource. Для начала представим ключевых лиц процесса.
-
Product Owner или Владелец Продукта. Определяет функционал, который команда хозяев готова принять от гостевых команд.
-
Contributor или Контрибьютор. Член гостевой команды, который отправляет код на ревью команде хозяев.
-
Trusted Committer или Доверенный Коммиттер. Представитель команды хозяев, наставляет и обучает Контрибьюторов, помогая создать и отправить Pull Request. В небольших продуктах роли Product Owner и Trusted Committer могут выполняться одним человеком.
Теперь рассмотрим план входящей контрибьюции по InnerSource.
-
Гостевая команда или Контрибьютор запрашивает функционал у команды хозяев.
-
Владелец продукта убеждается в том, что задачи по созданию функционала созданы в трекере гостевой командой или хозяевами. Описание требуемого функционала соответствует тому, что запросила гостевая команда, а также содержит информацию от команды хозяев по тому, как выглядит решение, которое будет принято в общую кодовую базу. Например, описаны возможные архитектурные ограничения, кодовые конвенции, использованые зависимости и контракты и тому подобное.
-
С поддержкой Trusted Committer, Контрибьютор оформляет код в виде Pull Request-а, где реализует необходимый функционал.
Обратите внимание, что шаги не описывают конкретную организацию рабочего процесса или способ приоритизации запросов. InnerSource предполагает, что в команде существуют устоявшиеся принципы работы и представляет решение, как совместить эти принципы с поступающими гостевыми контрибьюциями.
Этот вариант подходит для гостевой команды, так как они получают функционал, не беря на себя долгосрочные обязательства по поддержке решения. Это подходит для команды хозяев, так как они лучше масштабируются и обслуживают своих потребителей. Это подходит для компании в целом, так как общая проблема решена централизованно, в правильном домене, и каждый способен воспользоваться этим решением. Больше времени на разработку уходит на написание кода, который решает проблемы компании, вместо затрат на согласование и эскалацию.
Дополнительные ресурсы
-
Trusted Committer паттерн.
