我正在使用 Rational Team Concert (RTC) IDE 和 Jazz 构建引擎为 Spring Roo 应用程序设置持续集成构建。设置构建定义时，Jazz Source Control 选项卡上的 Build Workspace 字段允许选择用户的存储库工作区或流。
RTC 持续集成最佳实践和其他 Jazz 构建资源始终提到使用与构建用户关联的专用存储库工作区，这让我相信这是首选方法。我无法直接从流中找到任何有关构建的信息。我们项目的流包含构建所需的所有工件，我已经测试并确认持续集成构建从流中工作。我想不出为什么我需要为此目的创建和管理一个特定的工作空间。
我的问题是，我是在直接从溪流中建造出来玩火吗？这种方法是否存在我不知道的潜在下游并发症？
回答我自己的问题，以防其他 SO 用户将来有同样的问题。
经过一些实验，我发现直接从流构建的一个缺点是它忽略了 Jazz Source Control 选项卡上的“仅在接受更改时构建”属性。因此，来自流的构建只能以预定义的时间间隔进行 - 无法将构建配置为仅在向流提交新更改时发生。
构建需要一个专用的工作区来接受来自流的新更改并使用它们来触发构建请求。
这里还有另一个很大的不同。它与构建的完成方式有关。让我在这里强调一下区别。
如果您从专用的构建存储库工作区构建，那么您的构建工作区已经拥有所有代码的副本。当您的更改交付并开始构建时，只需更新更改的文件（您的更改集）并将其从存储库物理复制到构建存储库工作区。由于大多数更改都很小，这涉及从存储库复制 0.1% 到 2% 的代码库。
如果您从“流”构建，则需要创建构建工作区（您必须在某处编译！）。因此，当它被创建时，您的整个代码库需要更新并从存储库物理复制到构建存储库工作区。这意味着从存储库中检索 100% 的代码库。
每个文件操作都涉及调用以发现所需资源，从托管存储库的数据库中获取此资源，然后让 Jazz 应用程序通过网络提供此源文件。它会导致数据库服务器、Web 服务器和应用程序服务器上的负载。像这样下载的越多，对这些组件的负担就越大。
您可以使用一些方法来最小化 Jazz 基础架构上的这种负载。使用内容缓存代理（使用简单的 Squid 代理服务器）会有所帮助。
有关此处选项的更多详细信息以及这些选项的相对优点，请阅读我关于 Jazz Performance 问题的博客文章和白皮书 ( http://dtoczala.wordpress.com/2013/02/11/jazz-performance-a -提高性能的指南/）。那篇文章现在已经快一年了，但仍然有效。您还可以查看 Jazz Deployment Wiki ( https://jazz.net/wiki/bin/view/Deployment/WebHome )，并查看有关性能故障排除和性能问题的部分。