Стратегии разработки нескольких продуктов из одной кодовой базы

Question

Я работаю над проектом, который (скоро) будет разветвлен на несколько разных версий (Trial, Professional, Enterprise и т. Д.).

Я использую Subversion с момента ее первого выпуска (и CVS до этого), так что меня устраивает абстрактное понятие ветвей и тегов. Но во всем моем опыте разработки я когда-либо действительно работал над транковым кодом. В нескольких редких случаях какой-то другой разработчик (которому принадлежал репозиторий) просил меня внести изменения в определенную ветку, и я просто делал то, что он просил меня сделать. Я считаю «слияние» странным черным искусством, и я когда-либо пытался сделать это только под тщательным наблюдением.

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

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

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

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

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

Какие еще стратегии, рекомендации и советы вы, ребята, предлагаете?

---

UPDATE:

Ну, тогда ладно.

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

Я предполагаю, что некоторые из моих других опций:

1) Я всегда мог распространять полную версию программного обеспечения со всеми функциями и использовать лицензию для выборочного включения и отключения функций на основе авторизации в лицензии. Если я выбрал этот путь, я могу представить себе крысиное гнездо блоков if / else, вызывающих какой-либо объект «менеджер лицензий». Каков наилучший способ избежать спагеттизма в таком случае?

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

3) Если бы моя платформа поддерживала условную компиляцию, я мог бы использовать блоки #IFDEF и флаги сборки для выборочного включения функций. Это хорошо работает для больших, объемных функций, таких как целые графические панели. Но как насчет небольших, сквозных концертов ... таких как, например, регистрация или статистическое отслеживание?

4) Я использую ANT для сборки. Есть ли что-то вроде внедрения зависимости времени сборки для ANT?

Answer 1

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

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

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

Answer 2

Вы хотите сделать это через Subversion? Я бы использовал Subversion для поддержки различных выпусков (ветка на выпуск, например, v1.0, v2.0 и т. Д.), Но я бы посмотрел на создание различных выпусков (пробная / профессиональная и т. Д.) Из та же кодовая база.

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

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

Answer 3

Вы правы, что не прыгаете на ветвление и объединяете корзину так быстро. Это ПИТА.

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

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