持续交付（第二章）

在上一章中，作者列举了一些在软件开发中常见的问题，比如，手动部署项目，代码没有测试，团队协作没有采用版本控制系统等等，同时也告诫了我们一些避免的方法，在上述的一些问题中，我都不幸中弹了，也发现了自己的一些可以改进问题，领悟到一个道理：软件开发绝不仅仅是写代码而已。

在这一章作者向我们介绍了如何管理你的配置，刚看这一章时，我有点怀疑我之前理解的配置定义是正确的么？最后发现只是理解的有点片面了。

持续集成

配置管理是一个过程，通过该过程，所有与项目相关的产物，以及它们之间的关系都被唯一定义，修改，存储和检索。

配置管理通常与版本控制作为同义词出现，版本控制系统是配置管理的实现工具。配置管理所需要管理的内容不仅仅是项目源代码，有关项目的所有文件都应该被包含，比如，测试代码，数据库脚本，构建和部署脚本，文档，库文件和应用软件配置文件等等

版本控制系统是保存文件多个版本的一种机制。当修改某个文件后，你仍旧可以访问该文件之前的任意一个版本，极大促进团队的共同合作。

现在比较普遍常用的应该就是git了，使用版本控制系统的两个主要目的是，保留每个文件的所有版本的历史信息，使之易于查找，可以回到最近一次正确的版本中。提供基于元数据的访问方式，使元数据与某个单个文件或集合相链接。

还有一个很重要的点，那就是真的真的要对项目所有内容进行版本控制，这样一个极大的好处就是能够随时获取软件在生命周期中任意节点的文件状态，这样就可以选择从开发环境至生产环境整个环节的任意时间点，并将系统恢复至那个时间点。

依赖管理一般就是管理项目中所使用的第三方库，以及该项目需要用到的正由其他团队开发的模块或组件间的关系。

由于这些第三方依赖，一般来说都是二进制文件，且变更不频繁，所以到底要不要纳入版本控制系统中呢？我觉得可以不纳入，就存在本地就好了，这样也可以减少远程版本控制库的尺寸。

配置信息与产品代码及其数据共同组成了应用程序。
一般来说我们会在软件开发的任何时候都会进行软件的配置，因为很难做到那种一劳永逸的软件配置，并且这种配置也是很危险的。

将那些特定于测试环境或产生环境的实际配置信息存放在与源代码分离的代码库中是十分必要的，因为这些信息肯定与代码的更新频率是不同的，但是我们要保证两者具有相同的版本号

没有哪个应用程序是孤岛，每个应用程序都依赖于硬件，软件，基础设施以及外部系统才能工作，我们把这些称为软件的环境。

上面所说的那些组成环境的元素，我们都应该纳入版本管理系统，以及每次的变更都要有所描述并提交远程，对每个修改都要进行测试，以确保它不会破坏在新版本的环境中运行的程序。

环境管理也是可以使用工具来实现的，这样你就可以来声明一些事情，定义一些权限。

看完这一章，有解决之前遇到的问题，也有一些新的问题出现。

我的收获

我的疑惑

持续交付（第二章）—配置管理