<h2>配置管理</h2>
<strong>配置管理</strong>是指以汉人过程，通过该过程，所有与项目相关的产物，以及它们之间的关系都被唯一定义、修改、存储和检索。
<h4>使用版本控制</h4>
<strong>学到：</strong>
<strong>版本控制系统</strong>顾名思义就是管理开发中项目内容的系统，接触最多的是Git，使用它的好处是如果发现项目出错很容易滚回到上一个版本然后找到出错的地方也可以根据提交的历史记录找到是谁提交的哪部分代码出现了问题。
<strong>对所有内容进行版本控制</strong>
<strong>频繁提交代码到主干</strong>
<strong>使用有意义明显的提交注释</strong>
<strong>想到：</strong>
所以应该对所有内容进行版本控制，让整个项目透明化。
我们最容易忽略的事情就是对文档的记录，尤其是在使用版本控制的时候，我们很少会去提交文档，但是有的时候开发人员并不是在一起的，所以对使用的协议代码规范，或者测试用例各种并不能及时交流，可能会出现在最后发布的时间发现彼此依照的文档不同，导致整个项目的运行出错。
如果我们拿到的任务卡是一个比较大的模块，很多时候为了不必要的麻烦，我们会在彻底完成这个模块后再去提交，但是这样真的省去麻烦了么？当然是不一定的，在最后提交的时候，可能会和其他人提交的代码冲突，可能在别人引用的时候出错，可能会出现很多难以预料的问题。也有人喜欢新建单独的分支，当觉得自己代码 ok 的时候才去合并，同样的，这样的方法也是容易出错的。我们提倡，频繁的提交代码，保证你的代码随时不与项目里的其他人代码冲突。
提到注释，大家总觉得这不是那么重要，提交代码注释的时候也可能是“first commit”、“change bug”、“add page”等等这些模糊的没有多大意义的注释，但是如果项目出现了的bug是前面别的开发人员提交的代码导致出现的，那要怎么去处理，仅仅根据“change bug”你很难得出结论，他为什么要这样写，这个时候就深刻的意识到了注释的重要性。
<h4>依赖管理</h4>
<strong>学到：</strong>
现在的项目大多应该是在前人的肩膀上去实现的，导入一些依赖直接引用，但是这些外部依赖库文件要不要放入版本控制库中呢？每一次的pull与push都挺费时的，业界对这个问题一直都是存在争议的，具体怎么做还是根据具体项目要求自己衡量吧。
<h4>软件配置管理</h4>
<strong>学到：</strong>
<strong>配置信息与产品代码及其数据共同组成了应用程序。</strong>那么该如何管理系统配置？建议用对待代码的方式去对待系统配置，合理的去管理和测试。
<strong>配置的分类，</strong>构建、部署、测试、发布每一步都可以进行配置信息的设置。
<strong>应用程序的配置管理</strong>
如何描述配置信息？
通常配置信息以键值对的形式来表示，有时使用系统配置类型来有层次地组织这些配置项，也可以将配置信息以XML文件的形式来保存可以对其复杂性起到较好的限制效果。
部署脚本如何存取这些配置信息？
数据库、版本控制库、文件目录或注册表等。但是对主要的信息的存取需要施加限制。
在环境、应用程序各版本之间，每个配置信息有什么不同？
每个配置都是一个元组，但是取值取决于应用程序、应用程序的版本、版本运行环境三方面。
<strong>想到：</strong>
以前总觉得配置信息没有那么重要，主要是大家用的环境工具都是相同的，但是最近课设，和同学一起做项目，才真正感觉到了配置不同带来的麻烦，她写的代码在我这里根本不能运行，我写的代码她导入的方式不对也是无法合并的，看到这里意识到了配置信息的重要性。
<h4>环境管理</h4>
<strong>学到：</strong>
环境管理的关键在于通过一个全自动过程来创建环境，使创建全新的环境总是要比修复已受损的旧环境容易得多。
高效配置管理策略的两个基本原则：1.将二进制文件于配置信息分离；2.将所有的配置信息保存到一处。
<strong>变更过程管理</strong>应该严格控制生产环境，未经组织内部正式的变更管理过程，任何人不得对其进行修改。
<strong>想到：</strong>
环境重现也是很有必要得，如果我们修改的是别人写的代码，遇到问题可以想一下他当时的运行环境，明白他这样写的意义。
环境的也是需要自动化过程的，这样就会把变更的风险降到最低。
环境的破坏可能来自很小的变化，所以要记录每一次变更。
