2018-02-12-Kolko-Как Интегрировать Схему Разработки Одного Продукта В Другой
~~NOAPPROVE~~ Когда вы основываете свой проект на основе каких-либо библиотек или фреймворков, там все просто: вы берете последнюю стабильную версию и фиксируетесь на ней навсегда (либо до момента, когда не решите обновить зависимость в будущем). Этим вы повышаете стабильность вашего проекта, отделив схему разработки вашего проекта от его зависимостей, другими словами, вы не хотите в master-версии вашего продукта ловить баги свежей master-версии вашей библиотеки. Даже если вы проводите предварительное тестирование, вполне логично отказаться от новомодных фич и возможных багфиксов в пользу того, что у вас может всплыть внезапный баг, который не относится к вашим последним изменениям.
Все становится немного сложнее, когда зависимость вашего проекта - тоже ваш проект, общий для нескольких других проектов, либо проект, разрабатываемый отдельной командой. Ваша компания заинтересована, чтобы знания (фич-реквесты, багфиксы) от всех программистов стекались в этот проект о и чтобы не было локально заточенных версий этой зависимости в разных проектах.
Схема
Для примера, пусть это будет библиотека.
Все изменения для библиотеки должны проверяться мейнтейнером этой библиотеки, как в плане кода, так и идеологически. Изменения под один проект, использующий библиотеку, не должен влиять на другие проекты. При обновлении библиотеки в проекте мы должны иметь возможность ее протестировать на бета-версиях проекта.
Исходя из всего этого мы разработали следующую схему:
(Далее есть шарепроект1, проект2 и проект3. проект 2 и 3 используют в качестве зависимости шарепроект1. Не важно, шарепроект1 - это библиотека, демон, система сборки или фреймворк)
1. создается git шарепроекта1. Бранчи master, devel и integra в нем конфигурируются как protected, изменения в них может вносить только мейнтейнер(OSV: либо workflow аля github или аля kernel.git).
2. для шарепроекта1 разворачивается система сборки, которая синхронизирует master→devel→integra автоматически, позволяет «выпускать» новые версии, выполняя восходящий merge + выпуск ChangeLog (при необходимости), запускает тесты(OSV: посути просто разворачивается свой workflow).
3. все изменения создаются в бранчах разработчиков, далее оформляется merge-request в бранч integra на мейнтейнера(OSV: или на другой бранч если другой workflow).
4. проект2, когда начинает использовать шарепроекта1, создает себе potected-бранчи master_проект2, devel_проект2 и integra_проект2, основываясь на master-бранче. Изменения в эти бранчи может вносить только мейтейнер проекта2(OSV: если это сторонний проект можно создать свой gitlab и свои original).
5. если разработчик проекта2 хочет внести изменения в шарепроекта1 ОН ДОЛЖЕН(OSV: ЭТО САМОЕ ВАЖНОЕ) оформить это в виде merge-request в бранч integra(osv: или другой мейнстрим) на мейнтейнера шарепроекта1. После приема изменений разработчик может получить изменения, подпулив в бранчи своего проекта бранч integra, либо дождаться пока они попадут в master, либо сделав cherry-pick.
6. у шарепроекта1 в бранчах *_проект2 ЗАПРЕЩЕНЫ коммиты, которых нет в основных бранчах! Это необходимо для того, чтобы использование шарепроекта1 было идеологически-верным, все изменения проходили через его мейнтейнера и чтобы максимизировать выгоду от разработчика, чтобы разработчик проекта2 при улучшении шарепроекта1 в итоге помогал всем проектам, использующим шарепроекта1. Для проектов, развиваемых внутри компании это очень важно.
Основная идея в том, что все новые изменения в шарепроекте1 проходят через мейнтейнера шарепроекта1, а решение о переносе этих изменений в проект2 или проект3 (использующих шарепроекта1) принимали уже их мейнтейнеры
7. В определенный момент мейнтейнер проекта2 обновляет свой бранч шарепроекта1/integra_проект2 до бранча master. Бранч integra_проект2 используется при сборке integra его проекта, соответственно новая версия библиотеки проходит все этапы версий integra/devel/master его проекта и тестируются. И, при этом, все эти изменения не влияют на проект3.
Уточнения при конфигурации с форками:
Для удобства сборки проекта2, его мейнтейнер может создать форк шарепроекта1 и использовать его бранчи master/devel/integra для стадий его проекта. При этом добавление новых изменений делается через merge из шарепроекта1 в его форк, а все новые коммиты уходят в шарепроекта1 через pull-request/merge-request из бранча разработчика в бранч integra шарепроекта1 и уже после их приема могут попасть в форк.
Уточнения при конфигурации через быстрый master:
Когда шарепроектом1 не занимается отдельная команда разработки, поддерживать полный цикл master-devel-integra становится избыточно. В этом случае допустимо оставить только master-бранч и принимать все merge-request'ы в него. Благодаря тому, что это не попадает автоматом в проект2 и проект3 - считаем это безопасным.
Уточнения разных вариантов подключения зависимости:
Проект2 может забирать изменения шарепроекта1 разными способами:
- мейнтейнер проекта2 может периодически мержить integra_проект2 с master
- во время выпуска версии, после мержей devel → master и integra → devel может следовать автоматический merge шарепроекта1 master → integra_проект2
- проект2 может основываться на стабильности бранчей master-devel-integra шарепроекта1, считать что их периодичность выпуска синхронизирована с проектом2 и может использовать напрямую бранчи master-devel-integra. Самый ненадежный вариант. Хорошо подходит, если команда проекта2 также занимается и шарепроектом1 и сам шарепроект1, в основном, разрабатывается для проекта2 и в меньшей степени для других.
admin
Обсуждение