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