Version control «best practice»

Question

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

Сценарий:

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

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

Иногда запрос от клиента также включается в ядро ​​для распространения среди всех клиентов.

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

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

Благодарим за отзыв.

Антонио Диас

Answer 1

Я не знаю, почему вы думаете, что филиалы являются временными - они будут существовать до тех пор, пока вы хотите их.

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

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

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

Answer 2

Branches предназначены для изоляции «усилий по разработке» (здесь некоторые настройки), которые невозможно выполнить в тех же текущих ветвях.
Поскольку тэг предназначен для ссылки на «неизменяемый» контент, вы не должны делать никаких изменений в нем. Простой:

cvs tag -r MY_TAG -b MY_BRANCH 

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

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

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

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

Answer 3

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

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

Все будет еще хуже, если вы продолжите эту стратегию «один на один клиент» при добавлении новых клиентов.

Answer 4

Насколько я знаю, то, что вы делали, - это не то, что должно выполнять управление версиями. Он используется только для отслеживания исходного кода, а не для вашего распределенного продукта. На ваш вопрос о филиалах я думаю, что это небольшое объяснение может помочь: - магистраль является основной разработкой проекта, здесь сотрудничают все члены команды. - филиал - это место для временного развития (да, вы слышали это правильно). Здесь вы можете делать эксперименты или вмешиваться в код, не затрагивая других членов команды. - тег - это ничего, кроме «named snapshot». В моментальных снимках проекта управления версиями везде, тег - это способ, которым вы можете дать им более читаемое имя. Если вы попытаетесь получить все больше и больше филиалов без их распоряжения, ваш проект будет расти и расти навсегда. Я все еще удивляюсь, почему вы все равно должны отслеживать все это. Могу ли я повторить еще раз, контроль версий предназначен только для взаимодействия только с исходным кодом, а не для распространения среди нескольких клиентов. Надеюсь, что помощь

Answer 5

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

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

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

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

Или у вас может быть ваша базовая сборка/установка, а затем слой на настройках. Наложение пользовательских файлов и/или изменение базовых файлов.

Answer 6

Feature Branching is a poor man's modular architecture, instead of building systems with the ability to easy swap in and out features at runtime/deploytime they couple themselves to the source control providing this mechanism through manual merging. 

--Dan Bodart - через Martin Fowler

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