版本控制：
应该对所有的内容（包括源代码，构建脚本，测试，文档，需求，数据库脚本，代码库以及配置文件，开发，测试，运维的工具及所有环境及其配置等）进行版本控制，包括项目开发得所有产出而不仅仅是源代码，我们组课设因为没有将配置信息加入版本控制，导致大家的配置环境不同，整个程序不能完整的移植，只能根据交换部分代码。
频繁提交：
频繁提交会使得合并工作变得方便简单，大家可以及时的看到你的代码，并判断你的提交是否破坏了应用程序，如果发现错误可以及时回复到你提交前的状态，确保应用程序完好，而且你也以及及时修改错误（尤其是方向性的错误）防止这个错误影响后续的开发，可以提高开发效率。
不支持分支
创建分支不利于持续集成，在开发中所有人应该在主分支上频繁提交代码，为了确保提交的代码的正确性，我们需要在提交之前进行测试
提交注释很重要
有时候我在GitHub上提交代码时提交注释不知道怎么写就用 update 代替，导致查看时不知道上次提交修改了什么东西。所以每一次的修改或者增加都要尽可能详细的描述所做的工作。
需要注意的：
- 配置信息的版本要与相应的软件相匹配
- 将源代码与配置信息存放于单独的代码库中，有利于信息的安全性
- 构建流水线之间的依赖应该是二进制文件依赖，执行效率高，但是会给问题追踪带来困难，解决这一问题需要一个好的持续集成的服务产品
- 配置信息与代码同样重要
- 任何改变程序的行为都是编程，即使是修改一行配置信息
获取配置信息
- 使用文件系统可以跨平台，获得各种语言支持
- 从某个中心仓库获取配置信息
冒烟测试
“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。来源于硬件测试， 在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。 冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
高效配置管理策略的基本原则
- 将二进制文件与配置信息分离
- 将所有的配置信息保存在一处
小结
配置信息很重要，而且配置信息出错不易于查找错误原因，修改风险大，所以开发团队需要以谨慎的态度对待，对于课内实验环境的配置，我们可以采用写博客的方式将配置过程记录下来，方便大家查阅，或者将像 Java 的 jar 包之类的第三方库文件上传到 GitHub 上，一个团队尽量使用相同版本的库文件。
生产环境和测试环境要受到同等的重视，这两个环境要尽可能一致，这样可以减少部署时出现的问题。
疑问
- 对于配置信息的表示形式（键值对）不理解
- 为什么将配置信息以XML文件形式储存可以对复杂性起到限制效果？
- 系统配置的测试方法有哪些？
- 配置管理与持续集成，部署流水线的联系是什么？
