传统软件行业中的配置管理
虽然互联网、移动互联网的配置管理工作更有意思，但是我们还有 N 多的纯软件项目，所以我会抽出来讲讲传统的软件研发中怎么做配置管理。当然这部分也是做好配置管理的基础。很多知识、技能放到互联网企业里也是通用的。提到传统软件研发模式，我这里准备以 IBM RUP 模型作为例子来说。它把性能测试工具软件研发分成初始阶段、细化阶段、实现阶段和交付阶段。
· 初始阶段：项目启动阶段，明确系统的边界。这里主要回答的是我们要做一个什么样的软件，这个软件是用来做啥的。
· 细化阶段： 这个阶段主要是回答怎么去做这个软件。分析领域问题，制定详细的系统目标和范围、结构等，选择技术架构、编制计划等，为进一步的研发活动做好准备。
· 构造阶段： 简单说是开发+测试。
· 交付阶段： 确保软件可用。把软件交付给用户后，然后基于用户反馈进行一些修改，这里的修改一般为产品调整、设置、安装和可用性问题；结构问题应在早期阶段解决。
之所以通过 RUP 模型来说是觉得这四个阶段划分的更合理些，其实换成其它模型也可以。对于配置管理工程师来说大同小异。
话归正传我们来说说配置要做哪些事。
初始阶段
配置管理工程师要做的事情不多，主要是架构和项目决策上的事情，这里不多说。
细化阶段
从这阶段开始配置管理的工作来了。首先配置管理工程师要根据需求和架构文档、项目计划、质量保证计划等输出配置管理计划，准备好配置管理系统。
举个例子：项目架构文档说这个系统是 Linux 上基于 C和 C++开发，项目计划是下周开始编码，月底结束，测试说给我三天能发布（多么理想的状态）。这个时候配置管理计划里要把这些文字后面隐藏的信息挖掘出来
· 首先要找到需要的资源。有没有 Linux 机器？需要给研发一部分做开发机用，给测试人员搭建测试环境用，当然还有一部分是给自己做服务器用，包括管理代码的 VCS 服务器，管理 bug 的问题跟踪系统，自动化测试框架持续构建的构建机器，产品库。问题跟踪系统用什么？开源的 Redmine 还是需要 RMB 的 JIRA，都需要在这一步处理好。
· 其次挖出时间点：下周开始编码了，这必须得搞定啊，加班吧， 我的哥。
· 挖出项目人员： 给权限的给权限，该通知到的通知到。每个人都有什么职责、遇到什么事，找谁，谁来做主（谁来背锅）都得达成一致。平时不注意这些，关键时候找不到人如何是好。
构造阶段
一个字，干。没完成的继续完成，没干的赶紧干。计划一回事，干又是另外一回事。实际干的时候肯定和计划有出入，这个时候需要完善、更新配置管理计划这个文档，同时在配置管理系统中作出相应的配置，比如增加个字段啦，改个小流程了。同时做好配置管理审计，看看哪些东西缺少了，哪些做的不对了，对着公司的流程看一看，出个审计报告，项目例会上?啵?啵，也这点事。
交付阶段
苦逼的一个月过去了，准备交付。不断打标签，做构建，输出产品包给测试人员。测试人员拿包去测，提出缺陷，稍作修改。一个没有 p0 却带着 N 多 p1的产品发布出去了。这个时候，配置管理的工作除了正常的构建之外，还要支持补丁更新，分支合并等等。
往小了说吧，配置管理这么点事，一点技术含金量都没有，但是研发过程中却又必不可少。配置管理是一个技术、管理、流程都涉及的职位。往大了说吧，每一步都涉及公司的利益，看似一个个简单到不能简单的点，其实都和软件研发效率提高有关、和软件研发流程有关，和代码质量产品质量有关，做好一点点工作，对于公司都会有巨大的收益，比如简洁、清晰的分支模型，比如动车般的构建速度，比如准确的代码检查，比如可操作的代码规范等等。
上面说的这么多，看似很复杂，其实很多时候是在以前的配置管理计划模板的基础上改几个字，在以前的配置管理系统中配置几个字段的事情。随着时代的发展，以前那种呆板僵硬的管理流程和约束也在慢慢褪去。管它的配置管理计划，管它的公司流程，客户那边等着要呢，赶紧上线。这是现实，这也是现代软件研发对人员、流程、思想的要求。那么在现代的软件研发过程中，配置管理的很多规范、实践和流程都丢了么？Scrum 团队中不需要配置管理人员了么？肯定不是的。下一篇我将详细来讲，其实现在的工程实践把配置管理的很多方面做得越来越细，把很多方法论、流程、实践的东西做到了工具中，当你在使用工具的时候，不知不觉和配置管理在打交道。
页:
[1]