2018-02-12-Kolko-Как Интегрировать Схему Разработки Одного Продукта В Другой

Это старая версия документа.

Когда вы основываете свой проект на основе каких-либо библиотек или фреймворков, там все просто: вы берете последнюю стабильную версию и фиксируетесь на ней навсегда (либо до момента, когда не решите обновить зависимость в будущем). Этим вы повышаете стабильность вашего проекта, отделив схему разработки вашего проекта от его зависимостей, другими словами, вы не хотите в master-версии вашего продукта ловить баги свежей master-версии вашей библиотеки. Даже если вы проводите предварительное тестирование, вполне логично отказаться от новомодных фич и возможных багфиксов в пользу того, что у вас может всплыть внезапный баг, который не относится к вашим последним изменениям.

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

Для примера, пусть это будет библиотека.

Все изменения для библиотеки должны проверяться мейнтейнером этой библиотеки, как в плане кода, так и идеологически. Изменения под один проект, использующий библиотеку, не должен влиять на другие проекты. При обновлении библиотеки в проекте мы должны иметь возможность ее протестировать на бета-версиях проекта.

Исходя из всего этого мы разработали следующую схему:

(Далее есть проект1, проект2 и проект3. проект 2 и 3 используют в качестве зависимости проект1. Не важно, проект1 - это библиотека, демон, система сборки или фреймворк)

1. создается git проекта1. Бранчи master, devel и integra в нем конфигурируются как protected, изменения в них может вносить только мейнтейнер.

2. для проекта1 разворачивается система сборки, которая синхронизирует master→devel→integra автоматически, позволяет «выпускать» новые версии, выполняя восходящий merge + выпуск ChangeLog (при необходимости), запускает тесты.

3. все изменения создаются в бранчах разработчиков, далее оформляется merge-request в бранч integra на мейнтейнера

4. проект2, когда начинает использовать проект1, создает себе potected-бранчи master_проект2, devel_проект2 и integra_проект2, основываясь на master-бранче. Изменения в эти бранчи может вносить только мейтейнер проекта2.

5. если разработчик проекта2 хочет внести изменения в проект1 ОН ДОЛЖЕН оформить это в виде merge-request в бранч integra на мейнтейнера проекта1. После приема изменений разработчик может получить изменения, подпулив в бранчи своего проекта бранч integra, либо дождаться пока они попадут в master, либо сделав cherry-pick.

6. у проекта1 в бранчах *_проект2 ЗАПРЕЩЕНЫ коммиты, которых нет в основных бранчах! Это необходимо для того, чтобы использование проекта1 было идеологически-верным, все изменения проходили через его мейнтейнера и чтобы максимизировать выгоду от разработчика, чтобы разработчик проекта2 при улучшении проекта1 в итоге помогал всем проектам, использующим проект1. Для проектов, развиваемых внутри компании это очень важно.

Основная идея в том, что все новые изменения в проекте1 проходят через мейнтейнера проекта1, а решение о переносе этих изменений в проект2 или проект3 (использующих проект1) принимали уже их мейнтейнеры

7. В определенный момент мейнтейнер проекта2 обновляет свой бранч integra_проект2 у проекта проект1 до бранча master. Бранч integra_проект2 используется при сборке integra его проекта, соответственно новая версия библиотеки проходит все этапы версий integra/devel/master его проекта и тестируются. И, при этом, все эти изменения не влияют на проект3.

Уточнения при конфигурации с форками:

Уточнения при конфигурации через быстрый master:

Уточнения разных вариантов подключения зависимости: