我们有一个用于构建的配置规范,我们鼓励组织中的所有开发人员使用它,这样他们就可以在我们的构建中运行任何任务,而不用担心失败。每隔一段时间,我们就需要更新该配置规范,以包含新元素或排除旧元素。
当我们这样做时,这个过程是写一封快速邮件给我们的所有开发人员,告诉他们手动更新任何视图,他们使用当前的配置规范来构建我们的系统。
这是恼人的和容易出错的,因此导致许多开发人员忽略这些邮件,然后我们被调用,因为构建失败了。
我对以某种方式集中定义配置规范非常感兴趣,这样所有视图都可以使用该配置规范,并且我们可以在人员之下对其进行更新。这可能看起来很苛刻,但当你有数百名开发人员,他们都应该运行相同的构建时,这似乎是有意义的。
我已经研究过使用共享来存储配置规范,然后使用include行将其包含在开发人员的视图中,但是作为documentation states:“每次执行setcs和edc时,都会重新读取包含文件。”在测试中,这似乎意味着它似乎意味着,重新评估规则的唯一时间是在以某种方式编辑配置规范的上下文中。
我正在寻找的解决方案将在您每次与clearcase交互时重新评估配置规范,或者至少更新。这样,我就可以为每个人管理配置规范。
有什么想法?
发布于 2012-01-28 03:48:22
我可以工作,特别是如果你包含的配置规范不经常改变的话。
每次更改时,您的用户都必须运行
cleartool setcs -current(如example#2 of this technote中所述)
然后,您需要决定将该公共配置规范存储在何处:
共享驱动器上的
ClearCase视图上的
您可以看到一个full debate in this thread
然而,我遇到过一些情况,其中版本控制的包含文件是必要的,因为它引用了遗留代码中的大量元素,用户必须使用这些元素来继续他们在一些新代码上的工作。这是一种痛苦,我们不得不忍受它。
就像任何其他“过程”一样,这也需要对用户进行一些“教育”。
https://stackoverflow.com/questions/9039041
复制相似问题