Предложение модели ветвления для нескольких клиентов одного проекта

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

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

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

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

• Различные этапы для каждого клиента. Это означает, что каждая команда должна выпускать версии в разное время, а остальные коммиты не влияют на стабильность или их продукт.
• Различные требования, которые могут или не могут повлиять на ядро ​​системы в некоторых случаях.
• Большие команды (более 20 человек)
• Обработка ошибок в системе: что вы будете делать, если команда обнаружит в своем проекте ошибку, которая может повлиять на других клиентов?

Примечание. Мы говорим о проекте с 10 + M LOC.

Примечание. Мы используем Team Foundation System, Visual Studio 2008 и C # (в основном).

Любые предложения, источники или идеи о том, как справиться с ситуацией? Есть ли на рынке какая-либо модель с подобной проблемой?

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

Название для этого подхода - « Линии программных продуктов» или, иногда, « Линия разработки продуктов» . Со страницы Линии программных продуктов CMU SEI :

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

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

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

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

Некоторые дополнительные полезные ссылки:

• Википедия: линейка продуктов
• Тематические исследования CMU SEI
• Software Product Lines , сайт с большим количеством вводных материалов.

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

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

Если у вас нет общего глобального ядра, у вас будут такие же проблемы. Прежде чем я ушел из компании, мы обнаружили, что наш подход был неверным. Для поддержки такого сценария разработки нам потребовалось общее расширяемое ядро ​​и модель данных, которые будут настраиваться с верхних настраиваемых уровней приложения. Это ядро ​​должно использоваться в качестве основы для каждой индивидуальной настройки клиента и поддерживаться отдельной командой. Это будет связано с некоторыми сложностями в управлении, поскольку нескольким руководителям проектов потребуются ресурсы из одной команды, но это единственный способ сделать архитектуру согласованной, контролировать весь процесс и синхронизировать версии.

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

Например

• Выпуск 1.0 требует Библиотека A 1.0, Библиотека B 2.0, Библиотека C 5.6
• Для выпуска 2.0 требуется Библиотека A 1.0, Библиотека B 3.7, Библиотека C 5.7
• Выпуск 3.0 требует Библиотека A 1.2, Библиотека B 3.7, Библиотека C 5.8

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

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

Решением для вашей базовой системы может быть обращение с ней как с библиотекой, для которой вы поддерживаете разные версии. Что по сути означает, что вам нужно настроить разные ветви для каждой версии. Затем клиентское приложение может использовать правильную «версию» вашей базовой системы, ссылаясь на соответствующую ветвь папки базовой системы.

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

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