QA 负责质量、CM 负责构建、执行，属于被 QA 监控的质量一个环节。

关于软件升级维护、CM 环境搭建、账号管理 IT 完全可以胜任。我前几个月也仔细想过，配置管理与 IT 部门的区别，可能就在于配置项审计、变更管理、流程改进等文职性的工作。

刚和群里的聊过，你这个组合用来存储用户操作信息还行，控制权限也凑合，不过不适合多个中小型，维护类版本的权限控制。

:L 非常同情你的遭遇，不过很遗憾的告诉你，svn 存储不用数据库的。

应该是一个完整的 “起点” 好点吧？

merge 不是什么问题，严格操作，让研发人员从旁协助确认。 最主要的问题是，merge 完的 trunk 需不需要构建一个版本让测试人员确认下功能。

:( 能怎么办，我管理的几个项目，都有以前残留的毛病，都把单元测试代码扔进代码库里，虽然这样方便他们下一个版本的单元测试等。可是，给我怎么看，都不爽，因为，这些根本就不因该存在上线版本的代码内。

一、CM 关注点不应该是研发进度，这不是 CM 的工作范围 二、研发在构建前提交代码，CM 在构建前打 tag。（这个代码版本不是研发跳过 CM，已经得到测试人员验证通过的代码） 三、如果公司代码管理工具遭到研发抵触，作为 CM，有职责去了解、解决，研发人员的个人自由不由 CM 来限制（当然，前提是研发人员没有倒卖公司代码） 四、对立的情绪对公司的发展没有益处，大家是合作关系，你不给别人摆高姿态，别人同样也不可能摆高姿态来待你（前提：两者是同一水平线）

[[i] 本帖最后由 rexuekonglong 于 2010-3-10 17:25 编辑 ]

我的目标就是代码要被管理好，同时，研发人员不能排斥这件事。 刚才我也看了一下论坛上关于两种工具的对比，如果 cm 能给研发人员找出两者的差距，说服研发人员，那是最好。

另外，虽然代码是公司的资产，但同时也是研发人员的资产，研发自我资产保管的方式，CM 不应干涉。

[[i] 本帖最后由 rexuekonglong 于 2010-3-10 11:37 编辑 ]

下来看看内容！

回头看看，好像还有错别字:L 我的意思，不用去理会研发人员的代码管理工具，只要他们不闲麻烦和浪费时间，那就让他们在最后再把代码放回到 CM 的代码库区。只要公司的财产不会因此受到损失，还是别和研发的关系搞僵。

另一方面，也能看出这个 CM 和研发人员的关系相处的不融洽，既然研发喜欢新工具，那么你也应该去研究下。看看新工具是不是真的好用，如果正的好用。那么，你可以用新工具替代原来的工具。这样，代码管理也搞定了，和研发人员的关系也改善了，互相有益的事情。

这里要多讲讲人权！财产权！只要公司资产部首损失，什么都 OK

注意仔细看我的帖子， 那是两种不同的 CM 方向， 他们的关注点不同。单元测试报告保存下来，是为以后的回溯问题，留一个文字的证据。

学习 ing，这么难的题目，必须的学会应答……

多虑了！遇到冲突，当然要有相关研发人员来确认、解决冲突。让后构建版本提测，测试通过就可以定为发布版本。

讨论通过了，我的新表可以开始试用。我自己决定的审查记录时间，定为项目组正式提交 alpha 测试后。这样，最后的 beta 测试计划和 beta 测试用例也基本评审通过。

重新梳理下思路，咱们分两种情况来做。 一、项目级配置管理员（hudson 工具、未直接发布版本），完全可以在构建时形成单元测试报告，完全都通过后，在将构建包提交测试。 二、组织级配置管理员（发布版本），构建之前，需得到质量管理员的质量确认（其中包括对《单元测试报告》、《BUG 分析报告》等）后，根据 buildnote 执行发布构建，提交 alpha 测试/beta 测试。

至于，研发人员不愿意写书面报告的情况，必须通过行政手段推广，这个的益处是毋庸置疑的。对后来接任的研发及后续研发都有借鉴作用。

一样！我也没看到 people 这项，不过我现在也想通了，用户我建，权限我分，people 有没有一样。

少一个检查《单元测试报告》的环节。至少，这个研发小组长应该把这个工作但当起来。

眼前的情况，先凑合活下去，学习技能吧。有技能，什么都不怕

针对这个案例，有几种解决方案： 一、 将情况向上反映（研发总监），研发的操作，可以建议研发在申请 build 时，提供此次的《单元测试报告》 二、 从案例看出，这是项目级配置管理员的情况，研发、测试、CM 三者之间的沟通不够顺畅，应该坐下来好好谈谈 三、 可以让测试将这个问题升级向上级反映，改进下公司流程上的问题

你注意看，后面有个时间记录，也就是说要记录文档存档 SVN 的时间，还有就是前面有个文档数目，这 2 个就是审查项

:lol 我这张表是审计通过评审的，必须要进入基线库的文档，有问题的是不能通过评审进入极限的。

经过参考努力，基本搞定一张《项目基线审计表》

据我目前的观察，研发根本不关心配置库的状态，只关心代码的版本情况，以及他们该存档的文件。其他的东西，基本上研发的都不予理会。不过，我觉得你说 这个是咱们 CM 自我审查、自我改进的动力和参考，这点很正确:lol 不过我太懒了