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

Различия

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

Ссылка на это сравнение

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