Какова лучшая практика для организации различных приложений под VOB - PullRequest
Новая
       16

Какова лучшая практика для организации различных приложений под VOB

1 голос
/ 06 марта 2012

Это дополнительный вопрос к этому ответу: https://stackoverflow.com/a/9579131/1204799

"Лучше всего создавать корневые компоненты"

Если у меня есть несколько автономных приложений (что означает, что их разработка и развертывание являются независимыми), не следует ли мне создавать разные VOB для их размещения?Что я делаю сейчас, так это то, что у меня есть один отдельный PVob, который содержит несколько проектов UCM, каждый проект UCM имеет свой собственный Vob и базовый компонент (компонент без Vob).Я делаю это неправильно?

Обновлено 7 марта 16: 29

После того, как вы послушали ваш совет, я пытаюсь сделать следующее:

  1. Я создал один PVOB для размещения всех VOB
  2. Я создал один VOB для каждой бизнес-группы, которую в моей компании только три команды
  3. , которую я создалодин проект UCM для каждого приложения.Каждая бизнес-группа будет размещать несколько приложений, каждое приложение является довольно независимым, но каждое приложение может иметь более одной ветви для параллельной разработки, поэтому может быть много проектов

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

1 Ответ

0 голосов
/ 06 марта 2012

Лучше всего использовать несколько компонентов в (в общем) имени Vob.

Создание компонента для Vob не является «неправильным», скажем так, но вы должны знать, что, как только компонент был назначенКорневой каталог (например, Vob), вы больше не можете изменять этот корень или делать рефакторинг .

Под «рефакторингом» я ссылаюсь на классический случай, когда я создаю компонент«MyProject» (с его Vob '\MyProject' ... прежде чем, например, через несколько месяцев понять, что 'MyProject' на самом деле имеет сервер и клиентские модули, которые могут извлечь выгоду из отдельной истории: Iдолжен был определить два компонента, а не один.

С моделью «один vob на компонент» у меня нет другого выбора, как создать другой Vob: я не могу рефакторинг, то есть я не могу создать подкаталог в моем существующем компонентеи определите там второй компонент.

С помощью «нескольких компонентов на Vob» я могу:

  • переименовать мой первый компонент в «MyProject_Server» с его корневым каталогом«\MyVob\myproject'(который остается неизменным: вы не можете изменить корневой каталог компонента после его создания),
  • сделать другой компонент в том же Vob : "MyProject_Client" с корневым каталогом "\MyVob\myproject_client».

Основным преимуществом является масштаб : вы можете определить много (сотни) компонентов в Vob.
Но вы не должны определять сотни Vobs из-за явногочисло процессов (vobrpc_server и vob_server), необходимых для управления доступом к указанным Vobs.

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

Вы бы просто разделили эти компоненты вразличные проекты UCM и управление базовыми показателями каждого компонента в этих проектах UCM.

...