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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

EDIT:

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

Ответ 4

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

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

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

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