如何更好的控制基线后的配置项

xixiaojing666 · 发表于 2008-5-6 13:24:27

下面说说建立基线后的代码和文档的控制：
我们代码和软件工程的文档在建立基线后，控制手段不太一样。文档的控制是严格的按照变更流程进行执行的。配置项进入基线后，写权限就关闭了，只有读的权限。
流程如下：
变更申请->评估变更大小->审批变更申请->安排变更任务->执行变更任务->对更改后的配置项重新进行SCCB评审->结束变更
其中评估变更大小是由项目经理来进行评估；如果是大变更，项目经理交给SCCB来审批；如果是小变更，由项目经理进行审批。
但是单元测试完成后的代码基线，我们不般不把写权限进行关闭，因为在以后的测试过程中，变更的次数很多，所以只要开发人员在变更时通知PM、CM和相关人员，就可以了。

不知道各位是如何控制代码基线的，欢迎大家来讨论！

上一篇：关于产品分支管理的讨论
下一篇：Subversion培训教程

iamredeye · 发表于 2008-5-8 14:32:31

原帖由 xixiaojing666 于 2008-5-6 13:24 发表
配置项进入基线后，写权限就关闭了，只有读的权限。

能不能请教一下你们的lifecycle model是什么？waterfall，rup,agile，或近似?

fishred · 发表于 2008-5-8 15:48:32

我们一般按照系统上线来分，至于具体代码的变更，通过打标签来控制，至于流程上面大致时这样的：
需求变更－分析设计－评审－编码－发布，建立代码基线，代码基线是批量化的

iamredeye · 发表于 2008-5-8 20:23:15

楼上的只baseline代码?

这样的话在project level实际上基本上就没有change control了。在release level（如果存在的话）有change control，但只关注代码。

不知道我理解的对不对。

xixiaojing666 · 发表于 2008-5-8 21:07:33

原帖由 iamredeye 于 2008-5-8 20:23 发表
楼上的只baseline代码?

这样的话在project level实际上基本上就没有change control了。在release level（如果存在的话）有change control，但只关注代码。

不知道我理解的对不对。

代码基线也有变更控制,但是由于变更比较频繁,所以我们控制比较松.但是每个变更还是都记录的,一般用打标签的方法,便于追溯.

不是很理解你后一句话是什么意思:)
是说产品基线的变更只关注代码这个配置项吗?

xixiaojing666 · 发表于 2008-5-8 21:09:14

原帖由 fishred 于 2008-5-8 15:48 发表
我们一般按照系统上线来分，至于具体代码的变更，通过打标签来控制，至于流程上面大致时这样的：
需求变更－分析设计－评审－编码－发布，建立代码基线，代码基线是批量化的

代码基线是批量化的是什么意思?:)

xixiaojing666 · 发表于 2008-5-8 21:12:45

能不能请教一下你们的lifecycle model是什么？waterfall，rup,agile，或近似?

我们生命周期一般都是瀑布的,迭代的还没有用过,说实话对迭代模型还不是很了解.:loveliness:

要向我们论坛里的高手多多请教了:lol

[ 本帖最后由 xixiaojing666 于 2008-5-8 21:14 编辑 ]

iamredeye · 发表于 2008-5-8 22:19:52

瀑布的话cm比较容易。

“只”baseline代码实际上等于基本没有change control

lily_014 · 发表于 2008-5-8 23:50:32

原帖由 xixiaojing666 于 2008-5-8 21:12 发表

我们生命周期一般都是瀑布的,迭代的还没有用过,说实话对迭代模型还不是很了解.:loveliness:

要向我们论坛里的高手多多请教了:lol

是的,瀑布的比较好做.如果是迭代的按照你说的这样做将会有太多的基线变更.比如RUP模型,四个阶段里面又分各个阶段,特别是细化和构建阶段需求才慢慢完善,这时需求,设计,编码,测试一次次迭代那么基线该如何来做呢,一个迭代一个基线,用打标签的方式?....晚了改天继续讨论:)

[ 本帖最后由 lily_014 于 2008-5-9 11:29 编辑 ]

fishred · 发表于 2008-5-9 11:19:16

代码基线话，我们按上线来，因为每个月有多次上线，一次上线算一个基线

tongwds · 发表于 2008-5-9 11:54:02

我也很想知道：迭代模型、原型的配置库应该如何划分，如何才能更好的管理，希望这方面的高手讲解下

iamredeye · 发表于 2008-5-9 14:46:32

原帖由 fishred 于 2008-5-9 11:19 发表
代码基线话，我们按上线来，因为每个月有多次上线，一次上线算一个基线

这个当然没问题。但是CM要解决的主要问题是什么？change control！ “只”baseline代码说明没有主动去control，只是等change来了被动的做些处理而已，具体说就是实现些次要的version control之类的功能。

打个比喻：比如有些PM很自信，“我们根本不需要plan！为什么要plan？！we plan by doing!”他没错啊，为什么要plan呢，还要改来改去，直接做就好了！最后的结果就是他的plan，100％的一致！

不知道这个比喻会不会很垃圾:Q

xixiaojing666 · 发表于 2008-5-12 15:23:43

这个比喻很好，但是我觉得，真正能实现这个比喻的，恐怕没有。

细想想，计划都在头脑里，一周的事情恐怕能记清楚，但是一周以上的事情呢？
还有就是除非你自己一个人做项目，否则计划怎么沟通呢？别人怎么能知道你脑子里的计划？

iamredeye · 发表于 2008-5-12 22:01:24

你应该去train 那些pm:lol

rebeccazxy · 发表于 2008-5-22 15:52:35

关注！！！瀑布的确实比较好管理，迭代的感觉很容易管理混乱，或流于形式。请高手进来讲解下啊

如何更好的控制基线后的配置项

逛了这许久，何不进去瞧瞧？