ClearCase能否实现持续集成？

Question

我们在Jenkins服务器上运行夜间构建，并使用ClearCase作为源代码管理工具。

由于ClearCase是以文件为中心的，因此文件的检入操作是逐个进行的。与以仓库为中心的SVN或Git相反，开发人员的修改不会被原子地提交。

这在晚上并不成问题，因为开发人员不再活跃，而ClearCase服务器在凌晨1点时会锁定。

但以下是一个例子，说明在白天开发人员活跃时可能引起关注（假设每半小时运行一次构建）：

10:55 AM - Developer1 checks in element1
10:55 AM - Developer1 checks in element2
10:56 AM - Developer1 checks in element3
11:00 AM - ### Jenkins runs BUILD #1 ### <-- succeeds
11:29 AM - Developer2 checks in element1
11:29 AM - Developer2 checks in element2
11:30 AM - ### Jenkins runs BUILD #2 ### <-- fails (element3 is missing)
11:29 AM - Developer2 checks in element3

因此，对于ClearCase来说，发布版本（又称“尽快发布版本”或字面意思上的“持续集成”）是否值得考虑？我们是否注定要一直满足于夜间构建？

- Stéphane Bruckert

Answer 1

如果您正在使用UCM，您也可以考虑ClearCase UCM插件，并且仅在创建基线时按需触发构建。

这样做的好处是：

- 开发人员可以控制何时适合进行持续构建，只需添加一个基线（如果需要，清除旧的基线）。 - Jenkins可以推广基线，使跟踪成功或失败的构建更加容易。

您甚至可以为开发人员提供脚本来执行以下操作：

- 检查所有当前已检出的文件 - 自动设置一个基线

这将有助于用户触发连续集成，因为他/她可以决定当前代码库何时足够稳定以进行提交（和测试）。

---

您仍然可以在基本的ClearCase中使用该想法：只需确保在所有文件上放置一个移动标签（移动意味着：如果文件具有带有该标签的先前版本，则该标签将移动到开发人员刚刚签入的最新版本）。

您的Jenkins CC视图将被配置为显示具有该标签的所有文件，这意味着如果该标签移动到新版本，则Jenkins执行的cleartool lshistory将更改，并将触发构建。 （注意：您尚不能对标签模式执行此操作）

- VonC

---

谢谢回答。我应该指出; 我们不使用UCM，而只使用基本的ClearCase。那么，在不使用UCM的情况下，可能的答案是什么呢？ - Stéphane Bruckert

@StéphaneBruckert 我已经编辑了我的答案：想法是基于标签触发构建，而不仅仅是新的检入文件。 - VonC

Answer 2

有一个Clearcase插件https://wiki.jenkins-ci.org/display/JENKINS/ClearCase+Plugin，看起来实现起来有些复杂，但最近有更新。

另一方面，你可以连接到git/svn 如何将git与ClearCase桥接？

- KeepCalmAndCarryOn

---

事实上，我们已经在使用这个插件。我在想这个插件是不是只在晚上有用，在白天变得没用了？ - Stéphane Bruckert