其实我不愿意把这一篇起这个名字，配置管理就是配置管理，哪来那么多限定。我也不愿意，奈何有些人，尤其是互联网公司招人的人更青睐于那些从互联网公司出来的人，尤其是 BAT 的。这些公司出来的人有些方面的确很不错，这个没办法，这是事实。很多软件企业在开发过程中没遇到、也不可能遇到的问题，这些互联网公司都遇到了，而且先于其他企业先解决了。也许解决的不是很完美，但是至少可以是一个可以工作、可以运转的方案。也就是说互联网企业里的配置管理的确与传统的软件企业有些不同，但这里的不同不是理论、原则的不同，而是很多实现方法上的不同。软件企业在向互联网转型的时候都可以参考这些(被拍在沙滩上的)前辈的经验。很多传统企业也是看中互联网企业出来的工程师的这些优点。这一点还是有必要说的。
其实中国的互联网行业也是有一个发展的过程的。一开始挖外企的人，模仿外企的做法，甚至做一个山寨的的工具等等，渐渐做得好了、做起来了才慢慢发展出一些自己的东西，这也是近些年才有的事儿。在一些原创性比较强的领域，我们距离美国，尤其是西海岸的那些公司还是有差距的。
思绪收回来，我们还是分六个方面分别谈谈配置管理在软件企业和互联网企业做法的异同。
软件企业的赢利模式一般为卖软件。一个软件的许可(license)价格乘以购买的数量就是这个订单的收入(折扣等情况暂时不谈)。软件企业是通过软件本身的许可来赢利。什么时候需要购买或者升级许可的类型呢？一般为新购买软件或软件有重大的功能升级，也就是有重大版本发布的时候。两个大版本发布间隙之间，软件企业也会发布一些补丁，但是客户打这些补丁一般都是不收费的。中间发布的 sp 版本，则要看具体情况，有的公司收钱，有的则不收钱。但是大版本的升级，这个无论对于哪个软件公司，这个都是收费的。这就决定了软件企业不能一直不更新软件版本(没有新订单，公司的人员拿什么发工资)，但是也不能经常发大版本。一来是给用户使用做成了很大困扰，培训成本也会增加，刚熟悉了一个版本，下一个版本又来了。用户的体验就会下降，渐渐就会离你而去。
而互联网行业大多数则不是卖网站的，不是通过网站本身来赚钱的，而是通过提供具有附加值的服务来赢利。要想提供更多的附加值，就要不断把更多有价值的功能展现给用户，这就需要不断的上线。这个功能上线了，用户就能使用，用户就可能针对这个功能付费。
赢利模式决定了后面他们很多方面考虑的问题都不一样。
版本管理
在软件企业里，多数情况下一个代码库(code base)就是一个产品。这样做其实有很多好处。
- 权限容易控制。在软件企业里，权限管理、代码安全永远是重中之重。公司里各种各样的权限管理流程也能证明这一点。那么一个产品都放到一个库里，权限管理就特别集中，也容易进行权限控制。
- 容易集成。一个产品所涉及的方方面面所有东西都在一个库里，不需要到其它地方去找文档、找脚本、找配置、找代码，所有的东西都在这里，只要你有这个库的访问权限，那么你就可以编译这个产品，进行调试、开发等。
- 容易后期多版本维护。我们都知道软件企业的软件销售都不是一锤子买卖。卖软件许可只是一部分。软件卖出去后，还需要有软件实施、培训、后续二次开发等服务可以赚钱。另外软件发布出去后，还会有很多问题需要修复。所以就需要对软件不断的升级。时间一长就会发现，只要是发布过的版本都会有客户在用。显然每个版本一个分支有利于补丁的修复。更有甚者，要为大客户建立一个独立的分支，用来支持二次开发的需求。需要同时维护多个版本。
在互联网公司则情况却很不一样。我们都知道一个网站简单可以分为前端展示层、中间业务逻辑层、数据访问层，后台服务层等。因为我们不可能把所有的服务都部署到一台服务器上来同时满足几百上千万的用户访问，所以我们就要把这些服务等分别部署到不同的服务器上。这样的部署方式间接的也要求我们的版本管理上有相适应的管理方式。不同的功能、不同的服务要高内聚低耦合。一个服务一个代码库，一个模块一个代码库正好满足了这种方式。服务或者模块之间只要满足最新的版本之间互相兼容即可，不必背历史的包袱。线上版本一般就是最新的版本，互联网公司不存在线上跑几个版本的情况(灰度发布是另外一个情况)。简单总结就是：
- 权限管理相对开放
- 有很多的代码库，每个库都很小
- 每个库只要维护最新版本就可以
- 线上版本就是基线版本。所有 bug 的修复，功能的开发都要以线上版本为基准。
变更管理
因为需要支持多版本的并行开发和维护，所以变更管理对软件企业就十分的重要。哪个 bug 在哪个产品的哪个版本里出现了，在哪个版本里修复了，其他版本是否进行了代码合并要有清晰的跟踪记录。所以我们经常看到项目经理和研发人员对着问题跟踪系统，过里边的问题列表，需求列表。每次开项目例会，还会展示各种图表、看各种趋势图等。
互联网公司因为只需要维护一个基线版本，所以变更管理相对简单。这个 bug 线上出现了，那就在下个版本里修复，修复完上线。这个变更的链条相对短，而且处理周期也短，也许今天早上的 bug，晚上修复后就直接上线了。
构建管理
只支持一个平台的软件产品，构建管理相对简单；如果需要支持不同的平台，比如软件需要支持 Windows， Linux和Solaris，这个时候就要有三种构建环境。这个时候构建管理就相对复杂，因为要针对不同的操作系统做不同的构建脚本之类的。
网站相对简单多了，基于.NET 平台一般在 Windows Server 上构建；其它(Java,Php,Python 等)则都在 Linux 上构建，以后也直接部署到 Linux 上了，这样做很方便。
发布管理
发布相对不同更大，所以分几个要点来分析。
发布方式
软件企业是软件分发模式；互联网是自己的服务器直接部署模式。
互联网行业一诞生对于传统软件来说有一个巨大的优势就是距离用户近。我不需要把软件分发出去，不需要用户安装软件后才能享受到我提供的服务。所有的服务都在后端我来管理，用户只要打开浏览器，输入网址，立刻就能看到我的页面，使用我的功能。像以前还需要找部分用户发布 Alpha版，Beta 版，最终发布 GA 版，偶尔还要发布个 SP1，SP2，这些统统不需要。如果我需要更新某些功能，后台直接更新我的服务就可以了。上线即可直达用户。这种转变对于用户来说更直观、更具有冲击性。
发布周期
软件企业发布版本一般周期都比较长。因为在以前很多计算机都不具备上网的条件，软件升级版本的时候，真是要拿着软件一台机器一台机器去升级的。如果企业购买的软件每个星期都要升级一次，不用客户反馈，网管都会疯掉。所以软件企业(提供商)一般倾向于有节奏的去发布版本，比如1个月1个小版本，每三个月发布个 sp，半年发布个中间版本，一年发布个大版本。想尝鲜且有技术实力的可以跟随着补丁的发布，随时打补丁；而有些相对保守、更慎重的企业则会有计划的去升级。这样大家都可以接受。
互联网企业有发布周期么？互联网企业需要周期性发布产品么？没有，不需要。互联网企业的改动一般不会很大。哪个功能做好了，测试没问题直接上线就可以了。没必要去设立什么周期。功能做完，没啥问题，直接上线。对于功能变化较大、涉及模块很多的一般需要项目经理来协调，设定上线计划。
发布流程
软件企业发布个软件要经历很长的一长串流程？ why？ 因为传统软件发布软件的成本太高了，从前期调研、形成方案、软件开发、软件测试、准备各种配套文档，安装文档、用户手册、把软件压制成光盘、给售后培训，发给渠道、渠道销售，有的甚至还需要厂家售后人员上门去升级等，等你真正拿到更新的软件时，距离软件发布早已经不知道多少天过去了。
互联网企业也需要需求分析，也需要开发测试，也需要上线(没有培训，不需要压制光盘，不需要收获培训等)，但是这一套流程都很简短，也就意味着很高效。在互联网企业里早上有个需求，晚上就要上线，这是很正常的。
部署管理
软件的部署小到网上下载个 exe,msi,或者 rpm,dmg 文件直接安装，大到需要有厂家的实施人员上门进行安装、配置还要进行性能优化。但有个底线，就是只要愿意花钱，厂家都可以帮你搞定。
而互联网公司一般都是内部研发的系统，不需要到外面下载(依赖的包、依赖的库除外)。因为体系架构设计和系统的要求，一般服务或者模块之间依赖较少，所以单个部署相对简单，但因为整个系统涉及部分繁多，且部署在很多服务器上，整体系统的维护相对需要更多的功夫。所有的坑，都要自己去填。
相比较来说，软件企业软件部署相对简单；互联网公司的单个服务、单个模块部署简单，但整体复杂。
环境管理
软件企业的产品构建环境因为涉及多平台的情况，较复杂。但部署环境相对单一。互联网企业的构建环境可能因为不同的技术、会有不同的依赖等，但是部署多数都是基于某一种平台，很少看到 Windows Server 和 Linux 混搭部署的情况。但因为互联网企业部署的线上和线下环境涉及的服务器数量巨大，所以整体管理难度很大，需要有专门的运维团队来管理。
小结
通过六个方面，简单介绍了配置管理在软件企业和互联网企业的一些做法的异同。总体来说有不同，但共性更大一些。所以软件企业里的配置管理工程师跳槽到互联网企业是没问题的，更适合去学习些不一样的思维，不过因为技术栈之间的差异，需要提前做好准备工作。