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