Workflow Clearcase UCM-如何处理流和组件？

我和我的同事相对需要使用Clearcase UCM来传递想法。目前，管理层已经为每个功能软件包创建了流，每个功能软件包都定义了接口并生活在分层体系结构中。开发人员根据正在使用的包创建子流，并尝试独立开发代码，但在初始开发期间，他们通常依赖于其他包。这导致我们的集成小组创建了系统构建，然后开发人员使用这些构建来创建适当的环境来开发他们的软件，并手动引入依赖项，即zip文件、补丁等

我的论点是，这是错误的，不是UCM打算如何使用，但我需要更熟悉UCM的人来确认我的信念

我认为流应该从功能的角度创建，而每个包都有一些功能，多个架构包有助于实现一些客户功能，称之为ABC。然后，将为ABC功能执行初始开发的每个架构组件的组件添加到流中。函数ABC的所有开发人员现在都在流中或在一些子流中工作，以完成该函数。一旦完成，您就有了每个UCM组件的基线，并且从UCM的角度来看，组件之间不存在任何绑定。有人声称，由于活动记录，这可能会在UCM内发生

注意：我同意，也许您不会永远以这种方式工作，但是在接口通常发生变化的初始开发过程中，您没有实现所有功能的所有接口，因此让多个组件在一个流中协同工作是最有意义的。稍后，您可以过渡到以体系结构包为中心的工作方式，其中每个包独立于另一个包中的更改

想法？抱歉发了这么长的帖子，我觉得细节是必要的

为每个功能软件包创建流 函数ABC的所有开发人员现在都在流中工作，或者在一组子流中工作，以完成该函数 是的，这几乎就是UCM的两种流的正常用法 唯一非常糟糕的用法是每个开发人员使用一个流，只是为了隔离，这将是疯狂的，就像

这两种模式是系统方法和组件方法，详见。 基本上，您希望在开发的初始阶段避免太多的合并或重定基址，并在开始时保持一个所有组件都可写的连贯系统。 然后，当API稳定后，您可以对每个可写组件执行一个流

注意：当您拥有一组定义良好的基线，这些基线以只读方式引用所有组件的稳定状态，并且您可以在其中部署和测试系统时，这并不妨碍您建立系统集成流。

---

这些流在一个或多个单独的集成UCM项目上进行维护。

我同意VonC。我更喜欢功能性方法

有一个ClearCase插件可以帮助您为您的用户流、视图、项目策略建立环境，无论您采取什么方法。只是谷歌关于clearEnv