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