MSF TFS CMMI 体验报告:什么时候Check In (签入) ?
什么时候Check In ?
好像不是什么问题,我记得我使用VSS6的时候,没有什么原则,随时都可以,想要备份一下代码就Check In一下。但是在 TFS中,Check In 是有原则的。
场景:
在Process Guide中,Check In涉及到的 Workstreams and Activities只有2个 :
l Fix a Bug
l Implement a Development Task
这意味着,至于这两种情况下需要签入。也就是说,只有这2个过程设计到代码的修改。同时也意味着,任何需要对代码的修改都会产生这2个任务。
在初次的设计开发中,当然会产生 Development Task,在Change Request中,也是要产生一个Development Task的。而且,只有Development Task Test和Review都完成了才签入。
问题:
问题来了,如果Development Task还没有完成,另外一个Change Request也涉及到这个Development Task的代码怎么办呢?
我没有想到什么好的办法,但是没有好的办法也总要有个解决的办法,最终决定,把Development Task做一次签入在做Change Request的Development Task。
避免的方法:
把Development Task划分的粒度减小,这样问题发生的机率就会小。
保证只有Development Task Test和Review都完成了才签入的好处:
代码和Work item之间保持一致的关联,记录完整的一致修改轨迹,便于以后恢复,查证和修改等。
posted on 2006-04-13 18:40 无为而为-凡事从积极的态度做起 阅读(1554) 评论(0) 编辑 收藏 举报