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之间保持一致的关联，记录完整的一致修改轨迹，便于以后恢复，查证和修改等。