配置管理相关经验
版本控制系统根本的目的要保留每个文件的所有版本历史信息，易于查找。版本控制系统主要有两个作用，第一是让分布式团队可以愉快地协作（它可以回答：某个特定版本由哪些文件和配置组成？ 什么时候修改了什么内容，谁修改的，为什么修改？）第二个是源代码、测试代码、数据库脚本、构建和部署脚本、文档、库文件和应用软件所用的配置文件。都应该纳入版本控制。
频繁提交代码到主干
有了配置管理系统之后，需要做的很重要的事情就是频繁提交代码到主干，这个很多时候我们会感觉到困难，毕竟总得去和其他人的修改相互交互不如一直自己在不变的情况下自己开发，但是频繁提交代码的益处远远大于坏处：
长时间不提交会让合并工作变得过于复杂
其他人可以看到你的修改，并与之交互
无论修改的是什么，要确保它不会破坏原功能
尽可能使用增量的方式开发新功能
提交代码之前运行测试套件。这个套件1、快速运转（10min）。2、比较全面
每完成一个小功能或一次重构之后就提交代码。
使用意义明显的提交注释
配置的相关经验
配置在很大程度上是比代码管理还要坑的存在，因为代码我们会用各个手段让他在每个系统都是同一状态，而配置往往容易被忽略。所以，对配置一定要慎之又慎。
修改配置不一定比修改代码风险低，高度可配置的软件往往会陷入陷阱。不建议在构建或者打包时就将配置信息植入，应该使用相同二进制包向所有环境中部署，也就是说配置一定要和代码分离。将配置文件签入版本控制库，将配置项的修改历史保留下来。写一个脚本，根据需要将适当版本的配置信息加载到数据库或文件目录中。这点非常重要，配置一定应该是从版本管理库中的文件读取的而不是手动去写的。管理配置最有效的方法是让所有的应用程序通过一个中央服务系统得到它们所需的配置信息。ESCAPE的开源工具可以通过一种REST借口方便地管理和获取配置信息。将环境名称传给部署脚本，由脚本从配置服务中读取适当的配置信息。尽量减少配置项，最好只保留哪些与应用软件具体运行环境密切相关的配置项
配置测试的策略：1、保证配置设置中对外部服务的引用是良好的。2、当应用程序一旦安装好，就要在其上运行一些冒烟测试。
配置相关的原则：
1、什么阶段注入什么配置信息，要与运维及支持团队一同讨论，看看有什么样的需求。
2、配置项和源代码保存在一起，配置项的值保存在别处。
3、应该通过自动化的过程将配置项从保存配置信息的库中取出并设置好。
4、配置系统应该能根据应用软件的版本，要部署的环境等提供不同配置值。并且容易看到。
5、配置项有明确的命名习惯。
6、配置信息是模块化且封闭的，某处配置项修改不应影响无关项。
7、DRY（Don‘t Repeat Yourself），每个配置元素系统中唯一
8、除非有必要，否则不新增配置项。避免对配置信息的过分设计
9、测试要覆盖部署和安装时的配置操作
跨应用的配置：
为每个应用程序维护一份所有配置选项的索引表，记录这些配置保存在什么地方，生命周期多长，如何修改他们。
运行每个程序的构建脚本时应该自动生成一份，如果做不到也得记录在wiki上。
运维团队应该可以通过生产系统的监控平台了解每个软件应用的配置信息，每种环境中的软件到底是哪一个版本。（Nagios，OpenNMS，OpenView）
第三方软件的管理：
第三方软件的配置和部署应该也纳入到我们统一的部署脚本中，那么选择第三方软件很重要的评估依据是能不能通过命令执行安装程序不需要用户干预，配置可以通过版本控制系统来管理。
评估时要问自己：
1、我们可以自行部署么
2、我们能对他的配置做有效的版本控制么
3、如何适应我们的自动化部署策略
配置变更管理：
任何对环境的变更进行过程管理。任何变更上线前都要经过测试，将其编成脚本，放在版本控制系统中。
