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

Здесь показаны различия между двумя версиями данной страницы.

--- черновики:2018-02-12-kolko-как_интегрировать_схему_разработки_одного_продукта_в_другой [12.02.2018 10:27]
nikolay_carbonsoft1
+++ черновики:2018-02-12-kolko-как_интегрировать_схему_разработки_одного_продукта_в_другой [20.05.2019 15:18] (текущий)
@@ Строка 1: / Строка 1: @@
+~~NOAPPROVE~~
 Когда вы основываете свой проект на основе каких-либо библиотек или фреймворков, там все просто: вы берете последнюю стабильную версию и фиксируетесь на ней навсегда (либо до момента, когда не решите обновить зависимость в будущем). Этим вы повышаете стабильность вашего проекта, отделив схему разработки вашего проекта от его зависимостей, другими словами, вы не хотите в master-версии вашего продукта ловить баги свежей master-версии вашей библиотеки. Даже если вы проводите предварительное тестирование, вполне логично отказаться от новомодных фич и возможных багфиксов в пользу того, что у вас может всплыть внезапный баг, который не относится к вашим последним изменениям.
-Все становится немного сложнее, когда зависимость вашего проекта - тоже ваш проект, общий для нескольких других проектов, либо проект, разрабатываемый отдельной командой. Ваша компания заинтересована, чтобы знания (фич-реквесты, багфиксы) от всех программистов стекались в этот проект и чтобы не было и чтобы не было локально заточенных версий этой зависимости в разных проектах.
+Все становится немного сложнее, когда зависимость вашего проекта - тоже ваш проект, общий для нескольких других проектов, либо проект, разрабатываемый отдельной командой. Ваша компания заинтересована, чтобы знания (фич-реквесты, багфиксы) от всех программистов стекались в этот проект о и чтобы не было локально заточенных версий этой зависимости в разных проектах.
+===== Схема =====
+Для примера, пусть это будет библиотека.
+Все изменения для библиотеки должны проверяться мейнтейнером этой библиотеки, как в плане кода, так и идеологически. Изменения под один проект, использующий библиотеку, не должен влиять на другие проекты. При обновлении библиотеки в проекте мы должны иметь возможность ее протестировать на бета-версиях проекта.
+Исходя из всего этого мы разработали следующую схему:
+(Далее есть шарепроект1, проект2 и проект3. проект 2 и 3 используют в качестве зависимости шарепроект1. Не важно, шарепроект1 - это библиотека, демон, система сборки или фреймворк)
+. создается git шарепроекта1. Бранчи master, devel и integra в нем конфигурируются как protected, изменения в них может вносить только мейнтейнер(OSV: либо workflow аля github или аля kernel.git).
+. для шарепроекта1 разворачивается система сборки, которая синхронизирует master->devel->integra автоматически, позволяет "выпускать" новые версии, выполняя восходящий merge + выпуск ChangeLog (при необходимости), запускает тесты(OSV: посути просто разворачивается свой workflow).
+. все изменения создаются в бранчах разработчиков, далее оформляется merge-request в бранч integra на мейнтейнера(OSV: или на другой бранч если другой workflow).
+. проект2, когда начинает использовать шарепроекта1, создает себе potected-бранчи master_проект2, devel_проект2 и integra_проект2, основываясь на master-бранче. Изменения в эти бранчи может вносить только мейтейнер проекта2(OSV: если это сторонний проект можно создать свой gitlab и свои original).
+. если разработчик проекта2 хочет внести изменения в шарепроекта1 ОН ДОЛЖЕН(OSV: ЭТО САМОЕ ВАЖНОЕ) оформить это в виде merge-request в бранч integra(osv: или другой мейнстрим) на мейнтейнера шарепроекта1. После приема изменений разработчик может получить изменения, подпулив в бранчи своего проекта бранч integra, либо дождаться пока они попадут в master, либо сделав cherry-pick.
+. у шарепроекта1 в бранчах *_проект2 ЗАПРЕЩЕНЫ коммиты, которых нет в основных бранчах! Это необходимо для того, чтобы использование шарепроекта1 было идеологически-верным, все изменения проходили через его мейнтейнера и чтобы максимизировать выгоду от разработчика, чтобы разработчик проекта2 при улучшении шарепроекта1 в итоге помогал всем проектам, использующим шарепроекта1. Для проектов, развиваемых внутри компании это очень важно.
+Основная идея в том, что все новые изменения в шарепроекте1 проходят через мейнтейнера шарепроекта1, а решение о переносе этих изменений в проект2 или проект3 (использующих шарепроекта1) принимали уже их мейнтейнеры
+. В определенный момент мейнтейнер проекта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 и в меньшей степени для других.

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

Различия