Каков наилучший способ управления версиями продуктов и ветвления долгосрочных проектов?

В общем смысле, для долгосрочных проектов, которые могут иметь несколько выпусков в течение жизненного цикла продуктов и требовать поддержки предыдущих продуктов, каков наилучший способ обработки версий продуктов и ветвления базы кода?

В более конкретном смысле, предположим, что имеется надлежащий распределенный контроль версий (т. Е. Git) и что команды имеют небольшие или большие размеры, и что разработчик может работать над несколькими проектами одновременно. Основная проблема, с которой сталкиваются, заключается в том, что существует контрактное обязательство поддерживать старые версии, поскольку они существовали в то время, что означает, что новая разработка не может исправлять старый код (например, продукты Microsoft Office могут быть получены только для год выпуска, которым вы владеете).

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

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

Хорошим примером набора решений может быть:

Вещи, без которых мы не можем жить:

• быть в состоянии восстановить любой прошлый релиз в любое время
• иметь возможность поддерживать несколько поддерживаемых основных версий продукта в любое время

Вещи, которые мы хотели бы иметь:

• быть в состоянии выполнять текущую разработку основных функций (для следующего основного выпуска), не беспокоясь о слиянии веток
• быть в состоянии выполнять обновления обслуживания предыдущих выпусков

Вещи, без которых мы можем жить:

• автоматическая регистрация изменений от текущей работы к прошлым выпускам
• никогда не прерывайте разработку основных функций даже на несколько дней или неделю

Если вышеизложенное было вашими целями, вы могли бы принять такой процесс:

1. Сделайте всю работу по разработке на стволе вашего VCS ("master" в git)
2. Когда вы близки к основной версии, остановите разработку основных функций и сосредоточитесь на стабильности системы в течение недели или около того.
3. Когда ствол кажется стабильным, создайте ветку для этого основного выпуска
4. Разработка основных функций теперь может продолжаться в стволе, в то время как в ветке разрешены только исправления ошибок и подготовка к выпуску.
5. Однако все исправления ошибок, которые необходимо внести в ветку, должны сначала быть проверены на соединительной линии; это гарантирует, что они также будут присутствовать во всех будущих выпусках
6. Создайте тег (VCS) в ветви, когда вы будете готовы к выпуску; этот тег можно использовать для воссоздания релиза в любое время, даже после дальнейшей работы над той же веткой
7. Дальнейшие выпуски поддержки для этого основного выпуска (второстепенные выпуски) теперь могут быть подготовлены в ветви; каждый будет помечен перед выпуском
8. В то же время, разработка основных функций, ориентированных на следующий основной выпуск, может продолжаться в магистральной сети.
9. Когда вы приблизитесь к этому выпуску, повторите описанные выше шаги, создав новую ветку выпусков для этого выпуска . Это позволяет одновременно иметь несколько основных выпусков, каждый в своей ветви, в поддерживаемом состоянии с возможностью выпуска отдельных вспомогательных выпусков для каждого из них.

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

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

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

Git - это инструмент контроля версий - он управляет версиями файлов. Что вам нужно, это инструмент управления конфигурацией. Thereslyly из этих доступных, но в основном на высоких $$$ от таких как IBM.

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

Я не знаю, но уверен, что это будет существовать, добавление инструмента CM для Git.

Этот вопрос, похоже, очень похож на другой вопрос, на который я недавно ответил .

Короче говоря, это больше похоже на проблему дизайна и распространения продукта, чем на проблему управления версиями / ветвления. Конечно, мне легко это сказать, и вам труднее исправить, если вы уже глубоко погружены в проблему.

Не зная более подробно специфику вашей конкретной проблемы. В целом, однако, если бы у меня было несколько версий продуктов, основанных на кодовой базе, которая имела большой объем общего кода между продуктами, если бы это было выполнимо, я бы хотел реорганизовать продукты таким образом, чтобы сделать их более модульными, и убедитесь, что сами модули не требуют дополнительного ветвления кода. Я также посмотрел бы на мою модель развертывания, чтобы увидеть, есть ли лучшие средства для поддержки моих клиентов, сохраняя при этом большую часть кодовой базы унифицированной. Там, где требуется особая настройка заказчика, может потребоваться большая детализация модулей, чтобы уменьшить количество дублирующегося кода в системе.

Это непростая задача, но ее можно решить поэтапно, если вы хорошо справляетесь с работой, и если вы можете запланировать работу так, чтобы вам не нужно было «обновлять» все сразу.