Управление несколькими ветками кода и доставками

Question

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

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

Есть ли у вас опыт работы с такой ситуацией и как с ней справиться практически без перегрузки тестированием и работой (наши ежемесячные тесты выпуска занимают около 3 дней компьютерного времени)? И как управлять версиями, как вы справляетесь (я думаю, что cvs наконец-то придет ...)?

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Спрятать функции легко, поддержание нескольких одновременных версий - кошмар!

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

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

Answer 3

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

Я работал над некоторыми подобными проектами. и что мы сделали, имели ветку Commom для основных функций системы и ветку «Клиент» для каждого варианта продукта, таким образом вы можете реализовать определенные функции и исправления ошибок для каждого клиента и при этом использовать те же изменения в «commom» «ко всем вариациям продукта.

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

EDIT:

Кроме того, у вас должна быть (если еще нет) система отслеживания ошибок, в которой вы должны документировать клиент / филиал, над которым вы работаете.

Answer 4

Поддерживается только главный / основной ствол, если только в ветке нет исправления / функции, отсутствующей в основной строке.

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

Не делай этого.

Будь твердым.