持续交付二——配置管理

配置管理

看过书中对于配置管理的定义之后，还是不明白配置管理到底是什么。通过后面内容的讲解，对配置管理有了一些简单的理解。
配置管理与版本控制往往作为同义词，版本控制是保存文件多个版本的一种机制，而配置管理是对所有内容进行版本控制，管理依赖关系，应用软件的配置信息，也包括应用程序所依赖的软件，硬件和基础设施。

使用版本控制

这个方面我们虽然一直在坚持使用git把自己的代码提交上去，但是目前还没有做到将所有的内容都进行版本控制，频繁提交代码到主干进行小步提交能够让自己很清楚的知道自己这一步做了什么，在后来进行重构的时候也能够很快的知道自己应该去找哪一次提交的代码，同时，尽量详细的提交注释是写给自己最好的文档，能够帮助我们更快的找到自己对于代码的修改，并且在很久之后再看自己提交的也能够通过注释更快记起自己当时的行为。

依赖管理

• 外部库文件的管理：自己平时对于这个没有很好的习惯，自己之前也遇到过因为两个人的库文件版本不同的问题运行结果不同的情况，但是当时并没有注意到这一点。是否对外部库文件进行版本控制虽然各有利弊，但是还是看团队之间的协作吧。
• 组件管理：我认为组件管理就是能够把一个很大的项目划分成很多个模块进行开发，最后再进行合并，在自己的项目开发中，也会把整个大的问题划分成不同的层，每个层又有相对应的类似于组件的模块，对于划分的很清楚的模块来说，以后如果要修改的话就很容易找到位置，而对于组件划分不够明显的来说就很麻烦了。

软件配置管理

对于这个部分之前没有太了解过，看完作者的介绍，应该以对待软件代码的方式对待自己的软件配置。自己通常认为修改配置的风险要比修改代码的风险低，但是事实并不是这样，代码可以进行测试但是配置不可以。任何改变应用程序的行为，无论修改了什么，都算是编程。

环境管理

每个程序都需要依赖硬件，软件，基础程序以及外部系统才能工作。环境管理的关键在于通过自动化过程来创建环境，通过使用一些环境管理的工具也能够帮助我们解决不少需要自己手动解决的问题。对于变更过程管理，我的理解是大家共同使用一种环境，并且在没有大家商讨的情况下不要改变目前的环境，控并制变更的管理。

小结

这一章主要对于配置管理给出了很多我们在现实开发中容易犯的错误或者是经常被我们忽略掉的东西，但是对于软件配置的管理还是不太清楚，什么能够归于软件的配置，应该怎么进行管理，接下来还是需要再跟小组讨论一下。