在VOB下组织不同应用程序的最佳实践是什么

本文介绍了在VOB下组织不同应用程序的最佳实践是什么的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

这是此答案的后续问题： stackoverflow/a/9579131/1204799

最好创建基于根的组件

如果我有几个独立的应用程序（这意味着它们的开发和部署是独立的），我是否应该创建不同的VOB来容纳它们？我现在要做的是，有一个PVob，其中包含几个UCM项目，每个UCM项目都有自己的Vob和基准组件（一个没有Vob的组件）。我做错了吗？

3月7日16:29更新

在听取您的建议之后，这就是我现在要做的事情：

我创建了一个PVOB来容纳所有VOB

我为每个业务团队创建了一个VOB，而在我公司中，只有三个团队

我为每个应用程序创建了一个UCM项目。每个业务团队将托管多个应用程序，每个应用程序都是独立的，但每个应用程序可能有多个分支进行并行开发，因此可以有很多项目

这是我的问题：现在有几个应用程序共享同一个VOB，我如何更好地管理基线以便将它们组织起来通过应用程序？例如，为防止意外选择另一个项目的基线

解决方案

最好在（通常）名为Vob的内部使用多个组件。 / p>

每个Vob制作组件并不是说错的，但是您需要知道，一旦为组件分配了根目录（如Vob），您无法再更改该根目录或进行任何重构。

通过重构，我提到了创建组件的经典案例 MyProject （及其Vob' \MyProject '...，例如，在实现几个月之前后来， MyProject 实际上有一个服务器和一个客户端模块，可以从单独的历史记录中受益：我应该定义两个组件，而不是一个。

使用每个组件一个vob模型，我别无选择，只能创建另一个Vob：我无法重构，即无法在现有组件中创建子目录，并且无法定义那里是第二个组成部分。

有了每个Vob的多个组件，我可以：

• 重命名我的第一个组件为 MyProject_Server ，其根目录为 \MyVob\myproject （保持不变） ：创建后就无法更改组件的根目录）。
• 在同一Vob中创建另一个组件： MyProject_Client ，其根目录为 \MyVob\myproject_client 。

主要优势在于 scale ：您可以在一个Vob中定义许多（数百个）分量。 br> 但您不应定义数百个Vob，因为进程数量庞大（ vobrpc_server 和 vob_server ）需要管理对所述Vob的访问。

如果您为每个Vob创建多个组件，则不会对每个项目UCM的基准选择都有任何影响。 也就是说，无论是完整的Vob还是Vob的一部分，选择错误组件的基准的风险都一样大。 / p>

您只需将不同的UCM项目中的那些组件分开，并管理那些UCM项目中的每个组件基线。

This is a follow up question to this answer: stackoverflow/a/9579131/1204799

"It is best to create root-based components"

If I have several standalone applications (which means their development and deployment are independent), shouldn't I create different VOB to accommodate them? What I'm doing now is that, I have one single PVob, which contains a few UCM projects, each UCM project has its own Vob and baseline component(a component without Vob). Am I doing it the wrong way?

Updated at Mar-7 16:29

After taking your advice, this is what I am trying to do now:

I created a single PVOB to accomodate all the VOBs

I created one VOB for each business team, which, in my company, only three teams

I created one UCM project for each application. Each business team will host several applications, each application is rather independent, but every application may have more than one branch for parallel development, so there can be a lot of projects

Here comes my question: Now several applications are sharing the same VOB, how can I better manage the baselines so that they are organized by applications? i.e. to prevent accidentally choosing baselines of another project

解决方案

It is best to use multiple components within a (generically) named Vob.

Making a component per Vob is not "wrong" per say, but you need to know that, once a component has been assigned a root directory (like a Vob), you can no longer change that root, or make any refactoring.

By "refactoring", I allude to the classic case where I create a component "MyProject" (with its Vob '\MyProject'... before realizing, for example, a few months later that 'MyProject' has actually a server and a client modules which could benefit from a separate history: I should have defined two components and not one.

With the "one vob per component" model, I have no other choice that to create another Vob: I cannot refactor, ie I cannot make a subdirectory within my existing component, and define a second component there.

With the "multiple components per Vob", I can:

• rename my first component as "MyProject_Server", with its root directory '\MyVob\myproject' (which remains unchanged: you cannot change the root directory of a component once created),
• make another component within the same Vob: "MyProject_Client", with a root directory '\MyVob\myproject_client'.

The main advantage is about scale: you can define many (hundreds) components within a Vob. But you shouldn't define hundreds Vobs, because of the sheer number of processes (vobrpc_server and vob_server) required to manage the access to said Vobs.

If you create several components per Vob, that won't have any influence on the baseline choice for each project UCM. Ie you would have as much risk of choosing the baseline of the wrong component, whether those components are a full Vob or are part of a Vob.

You would simply separate those components in different UCM projects, and manage each component baselines in those UCM projects.