配置管理
配置管理:指将所有与项目相关的产物,及它们之间的关系都被唯一定义,修改,存储和检索的过程.
配置管理记录了系统及应用程序的演进过程;管理了团队成员协作方式.
解决什么问题
配置管理价值:
- 可以再现任何所需环境(包括操作系统版本及其补丁,网络配置,软件组合,相关软件及其配置);
- 轻松对上述内容进行增量式修改,并将修改部署到任何环境;
- 很容易进行修改追溯,知道修改源,修改人,修改内容;
- 遵守必须规则;
- 团队成员可以轻易的得到所需的信息,并进行必要的修改.高效交付,缩短交付周期,快速反馈;
怎么做
具体包含内容:
- 对所有内容进行版本控制;管理依赖关系;
- 管理应用软件的配置信息;
- 管理整个环境的配置信息(软硬件配置);
- 版本控制
版本控制的目的:
- 保留每个文件的所有版本的历史信息,并使之易于查找;
- 便于分布式团队协助;
持续交付下的版本管理做法:
- 对所有内容进行版本管理;目的是便于从零,从任意状态开始部署应用,它管理的内容包括:源代码,测试代码,数据库脚本,构建和部署脚本,文档,库文件,应用软件配置文件,甚至包括编译器及工具集等;版本控制中不应该包含构建完的可执行文件,因为它比较大,同时它可以通过构建获得;可执行文件应该单独通过版本号管理,这样便于重用,同时也可以避免同一次构建进行多次构建,浪费资源;
- 频繁提交代码到主干;强调有质量的速度,通过快速实现功能,来加速软件价值的实现;软件质量保证方式:a.增加自动化测试,达到标准才能进入下级环节,来保证产品质量;b.进行增量式开发,小步快跑,来避免冲突和缩小单次提交影响范围;
- 使用意义明显的提交注释;便于问题内容了解,快速识别核心问题.尽量采取总结+详情描述+需求链接.
- 依赖管理
组件和依赖都是对于公共功能,工具的抽取使用,通过插件式管理,便于灵活更替,为软件迭代增加了灵活性;
依赖和组件的区别:
依赖是有使用权,没有控制权的第三方库文件,开放使用,一般版本比较稳定;
组件是公司内部开发软件,具有使用权和控制权,依赖内容的灵活性和适配性更强,但是这往往也意味着不稳定;
- 配置管理
应用程序由源代码,数据以及配置组成.实际中对于配置的管理,一直都不是很受重视,但是出问题配置问题恰恰是最多也是比较难第一时间想到的.
配置管理要考虑的内容
- 配置与灵活性.配置可以增加软件的灵活性,但是越是灵活的配置,它的软件复杂度就越高,发生问题的概率就越大,所以不是越灵活的配置越好.实际中对于配置的检测方式比较少,较好的一个实践是部署时进行配置的冒烟测试.
- 配置分类.依据应用集成配置的不同时点,可以分为:
- 构建时应用引入配置
- 打包时应用引入配置
- 安装部署应用引入配置
- 启动运行时应用引入配置.因为构建,打包时引入配置文件,会固话已经生成的二进制文件,因为往往配置是区分环境的,比如测试,预生产,生产等;你越晚集成配置文件,你的二进制包就越通用.因为实际测试和生产环境,除了配置文件其他完全一致,你完全可以共用它.但是java在这点做的不好,它同是开发时就强制注入不同环境的配置来提供服务,这也造成了二进制文件如果要共用就要换配置集成方式.
- 应用配置管理.实际配置管理需要明确:
- 如何描述配置信息.通常是键值对形式, 比如yaml,json,xml都比较好;
- 如何存取配置信息.可以存储在数据库,文件目录,注册表和版本控制库,甚至是环境变量中.但是推荐放到版本控制库,不仅是历史追溯还是安全性,都比较好;获取配置信息,通过配置中心服务(独立的配置服务)来获取配置文件,这一点就要求比较高;同时还可以使用文件目录方式,这种方式感觉没有java直接集成在resource目录下好,因为时间长了会忘记还有一部分外部依赖配置文件;
- 配置要尽量精简,可以提供一些配置默认值,不同环境通过覆盖该默认值即可,但是这种方式需要部署时验证,覆盖是否生效.具体配置(应用,系统)验证可以通过冒烟测试方式.
- 跨应用配置管理.
- 历史应用,或者未进行版本化管理的应用,需要维护一份所有应用配置的索引表,记录位置,生命周期,如何修改它们;
- 尽量版本化管理配置
- 管理配置的原则
- 明确配置引用的节点.构建时,打包时,部署时,运行时?
- 配置项单独管理.
- 自动化获取配置
- 配置系统可以根据应用,应用软件版本,部署环境,部署环节提供不同的配置值.
- 良好的配置命名
- 模块化管理
- 全局唯一
- 最少化
- 简单化
- 部署,运行时进行配置验证
- 环境管理
每个应用都依赖与硬件,软件,基础设施及外部系统才能工作.这些内容就是应用程序的环境.
环境管理就是像配置管理一样管理环境.通过环境管理的自动化,来控制所有环境,避免未知风险.
- 环境管理工具
- 变更过程管理