互联网行业的配置管理.docx

互联网行业的配置管理

其实我不愿意把这一篇起这个名字，配置管理就是配置管理，哪来那么多限定。我也不愿意，奈何有些人，尤其是互联网公司招人的人更青睐于那些从互联网公司出来的人，尤其是BAT的。这些公司出来的人有些方面的确很不错，这个没办法，这是事实。很多软件企业在开发过程中没遇到、也不可能遇到的问题，这些互联网公司都遇到了，而且先于其他企业先解决了。也许解决的不是很完美，但是至少可以是一个可以工作、可以运转的方案。也就是说互联网企业里的配置管理的确与传统的软件企业有些不同，但这里的不同不是理论、原则的不同，而是很多实现方法上的不同。软件企业在向互联网转型的时候都可以参考这些（被拍在沙滩上的）前辈的经验。很多传统企业也是看中互联网企业出来的工程师的这些优点。这一点还是有必要说的。

其实中国的互联网行业也是有一个发展的过程的。一开始挖外企的人，模仿外企的做

法，甚至做一个山寨的的工具等等，渐渐做得好了、做起来了才慢慢发展出一些自己的东西，这也是近些年才有的事儿。在一些原创性比较强的领域，我们距离美国，尤其是西海岸的那些公司还是有差距的。

思绪收回来，我们还是分六个方面分别谈谈配置管理在软件企业和互联网企业做法的异同。

软件企业的赢利模式一般为卖软件。一个软件的许可（license）价格乘以购买的数量就是这个订单的收入（折扣等情况暂时不谈）。软件企业是通过软件本身的许可来赢利。什么时候需要购买或者升级许可的类型呢？一般为新购买软件或软件有重大的功能升级，也就是有重大版本发布的时候。两个大版本发布间隙之间，软件企业也会发布一些补丁，但是客户打这些补丁一般都是不收费的。中间发布的sp版本，则要看具体情况，有的公司收钱，有的则不收钱。但是大版本的升级，这个无论对于哪个软件公司，这个都是收费的。这就决定了软件企业不能一直不更新软件版本（没有新订单，公司的人员拿什么发工

资），但是也不能经常发大版本。一来是给用户使用做成了很大困扰，培训成本也会增加，

刚熟悉了一个版本，下一个版本又来了。用户的体验就会下降，渐渐就会离你而去。

而互联网行业大多数则不是卖网站的，不是通过网站本身来赚钱的，而是通过提供具有附加值的服务来赢利。要想提供更多的附加值，就要不断把更多有价值的功能展现给用户，这就需要不断的上线。这个功能上线了，用户就能使用，用户就可能针对这个功能付费。

赢利模式决定了后面他们很多方面考虑的问题都不一样。

版本管理

在软件企业里，多数情况下一个代码库(codebase)就是一个产品。这样做其实有很多好处。

●权限容易控制。在软件企业里，权限管理、代码安全永远是重中之重。公司里各种各样的权限管理流程也能证明这一点。那么一个产品都放到一个库里，权限管理就特别集中，也容易进行权限控制。

●容易集成。一个产品所涉及的方方面面所有东西都在一个库里，不需要到其它地方

去找文档、找脚本、找配置、找代码，所有的东西都在这里，只要你有这个库的访问权限，那么你就可以编译这个产品，进行调试、开发等。

●容易后期多版本维护。我们都知道软件企业的软件销售都不是一锤子买卖。卖软件许可只是一部分。软件卖出去后，还需要有软件实施、培训、后续二次开发等服务可以赚钱。另外软件发布出去后，还会有很多问题需要修复。所以就需要对软件不断的升级。时间一长就会发现，只要是发布过的版本都会有客户在用。显然每个版本一个分支有利于补丁的修复。更有甚者，要为大客户建立一个独立的分支，用来支持二次开发的需求。需要同时维护多个版本。

在互联网公司则情况却很不一样。我们都知道一个网站简单可以分为前端展示层、中

间业务逻辑层、数据访问层，后台服务层等。因为我们不可能把所有的服务都部署到一台服务器上来同时满足几百上千万的用户访问，所以我们就要把这些服务等分别部署到不同的服务器上。这样的部署方式间接的也要求我们的版本管理上有相适应的管理方式。不同的功能、不同的服务要高内聚低耦合。一个服务一个代码库，一个模块一个代码库正好满足了这种方式。服务或者模块之间只要满足最新的版本之间互相兼容即可，不必背历史的包袱。线上版本一般就是最新的版本，互联网公司不存在线上跑几个版本的情况（灰度发布是另外一个情况）。简单总结就是：

●权限管理相对开放

●有很多的代码库，每个库都很小

●每个库只要维护最新版本就可以

●线上版本就是基线版本。所有bug的修复，功能的开发都要以线上版本为基准。

变更管理

因为需要支持多版本的并行开发和维护，所以变更管理对软件企业就十分的重要。哪个bug在哪个产品的哪个版本里出现了，在哪个版本里修复了，其他版本是否进行了代码合并要有清晰的跟踪记录。所以我们经常看到项目经理和研发人员对着问题跟踪系统，过里边的问题列表，需求列表。每次开项目例会