持续交付读书笔记二

配置管理

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

从我自己的经验，配置管理涵盖很多方面，最重要的一条准则就是需要把所有与项目相关的code、data、脚本等管理起来。

对于当前来说，配置管理等等是必须要使用版本控制系统来完成此管理能力。

对于如何高效的使用版本控制的几点建议：

1、对所有内容进行版本控制

2、频繁提交代码到主干（主要的原则是让增量的维度更小）

3、提交需要使用有意的提交注释

对于依赖管理，基于java的依赖管理，我们可以通过maven，同时对工程进行基础拆分，通过parent的方式来统一管理外部引入的基础依赖服务。

同时对于构建流水线中的依赖和上下文一定是二进制的制品。

配置的外延还包括了，软件配置和环境配置，对于这些的一切都应该被控制系统管理起来，基于此沿用一切皆代码的思路，我们应该把环境、软件配置、测试用例、基础数据模型和增量脚本都统一管理起来，并以产品和解决方案的维度来进行管理，并在相应的维度管理中增加DSL文件，通过可自描述DSL来实现对构建、测试和交付的全景流程描述，通过系统平台工具的引擎进行分析和执行，如通过CI的DSL完成此产品的持续构建，通过测试的DSL完成测试的自动化回归（包括对环境和应用依赖的描述分析），基于此理念一个基本的产品目录应该是如下模式：

针对一个产品的版本库目录结构如下：

CRM产品

├── payment（模块，产生容器镜像）

├──DATA

        └──data.dsl

        └──preinstall（预安装脚本）

        └──update（增量脚本）

├──ENV

      └──env.dsl(DSL,描述版本测试关联的环境和资源的要求以及基于什么镜像和组件的服务要求)

├──CI

        └──ci.dsl

        └──findbugs(findbugs相关的例外，规则等配置目录，以下类同)

        └──checkstyle

        └──pmd

        └──……

├──CASE

       └──CTU

        └──Case

        └──Client

        └──Data

        └──Function

        └──Job

        └──TU

        └──Var

├──target

├──Dockerfile

└──pom.xml