Jazz SCM持续集成-构建流与工作空间？

Question

我正在使用Rational Team Concert (RTC) IDE和Jazz构建引擎为Spring Roo应用程序设置持续集成构建。在设置构建定义时，Jazz Source Control选项卡上的build Workspace字段允许选择用户的存储库工作区或流。

RTC Continuous Integration Best Practices和其他Jazz构建资源一致地提到使用与构建用户相关联的专用存储库工作区，这使我相信这是首选方法。我还不能直接从流中找到任何关于构建的信息。我们的项目流包含构建所需的所有工件，我已经测试并确认了持续集成构建是从流开始工作的。我想不出有什么理由需要为此创建和管理特定的工作区。

我的问题是，我直接在小溪上建造建筑是在玩火吗？这种方法是否存在我不知道的潜在下游并发症？

Answer 1

回答我自己的问题，以防其他SO用户将来也有同样的问题。

经过一些实验后，我发现直接从流构建的一个缺点是它忽略了Jazz Source Control选项卡上的"Build only that changes“属性。因此，来自流的构建只能以预定义的时间间隔完成-不可能将构建配置为仅当新的更改已提交到流中时才发生。

构建需要一个专用的工作空间来接受来自流的新更改，并使用它们来触发构建请求。

Answer 2

这里还有另一个很大的区别。它与构建是如何完成的有关。让我在这里强调一下不同之处。

如果您从专用的构建存储库工作区进行构建，则您的构建工作区已经具有所有代码的副本。当您的更改被交付，并且构建被启动时，只需要更新已更改的文件(您的更改集)，并将其物理地从存储库复制到构建存储库工作区。由于大多数更改都很小，这涉及到从存储库复制0.1%到2%的代码库。

如果你从“流”构建，那么你的构建工作区需要被创建(你必须在某个地方编译！)。因此，在创建此代码时，需要更新整个代码库，并将其物理地从存储库复制到构建存储库工作区。这意味着从存储库中检索100%的代码库。

每个文件操作都涉及到一个发现所需资源的调用，从托管存储库的数据库中获取该资源，然后让Jazz应用程序通过网络提供该源文件。这会导致数据库服务器、web服务器和应用程序服务器上的负载。像这样下载的越多，这些组件上的负载就越大。

有一些东西可以用来最小化Jazz基础设施上的负载。使用内容缓存代理(使用简单的Squid代理服务器)会有所帮助。

有关您的选项的更多详细信息，以及这些选项的相对优点，请访问我的关于Jazz性能问题(http://dtoczala.wordpress.com/2013/02/11/jazz-performance-a-guide-to-better-performance/)的博客文章和白皮书。那篇文章现在已经快一年了，但仍然有效。您还可以查看Jazz Deployment Wiki (https://jazz.net/wiki/bin/view/Deployment/WebHome)，并查看有关性能故障排除和性能问题的部分。