首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >《持续交付:发布可靠软件的系统方法》第2章 配置管理

《持续交付:发布可靠软件的系统方法》第2章 配置管理

作者头像
yeedomliu
发布2019-09-28 13:00:52
6930
发布2019-09-28 13:00:52
举报
文章被收录于专栏:yeedomliuyeedomliu

第 2 章 配置管理

2.1 引言

  • 配置管理是指一个过程,通过该过程,所有与项目相关的产物,以及它们之间的关系都被唯一定义、修改、存储和检索
  • 配置管理策略将决定如何管理项目中发生的一切变化。它记录了你的系统以及应用程序的演进过程。另外,它也是对团队成员协作方式的管理

2.2 使用版本控制

  • 版本控制系统的目的有两个
    • 它要保留每个文件的所有版本的历史信息,并使之易于查找
    • 它让分布式团队(无论是空间上不在一起,还是不同的时区)可以愉快地协作

2.2.1 对所有内容进行版本控制

  • 每个与所开发的软件相关的产物都应被置于版本控制之下。开发人员不但要用它来管理和控制源代码,还要把测试代码、数据库脚本、构建和部署脚本、文档、库文件和应用软件所用的配置文件都纳入到版本控制之中,甚至把编译器以及工具集等也放在里面,以便让新加入项目的成员可以很容易地从零开始工作
  • 我们无论怎么强调“做好配置管理”都不算过分。我们所讨论的有关加快发布周期和提高软件质量的所有实践,从持续集成、自动化测试,到一键式部署,都依赖于下面这个前提:与项目相关的所有东西都在版本控制库中

2.2.2 频繁提交代码到主干

  • 使用版本控制时,有两点需要牢记在心
    • 首先,只有频繁提交代码,你才能享受版本控制所带来的众多好处,比如能够轻松地回滚到最近某个无错误的版本
    • 其次,一旦将变更提交到版本控制中,那么团队的所有人都能看到这些变更,也能签出它。而且,如果使用了持续集成(像我们推荐的那样),你所做的修改还会触发一次构建,本次构建很有可能会最终进入验收测试,甚至被部署到生产环境
  • 有些人解决这个两难问题的方法是,在版本控制系统中为新功能建立单独的分支。到某个时间点后,如果这些修改的质量令人满意,就将其合并到主干。我们对这样的做法持反对意见
    • 它违背了持续集成的宗旨,因为创建分支的做法推迟了新功能的整合,只有当该分支被合并时才可能发现集成问题
    • 如果多个开发者同时分别创建了多个分支,问题会成指数增加,而合并过程也会极其复杂
    • 尽管有一些好用的工具有自动合并功能,但它们无法解决语义冲突
    • 它让重构代码库变得非常困难,因为分支往往涉及多个文件,会让合并变得更加困难
  • 一个更好的解决方案是尽量使用增量方式开发新功能,并频繁且有规律地向版本控制系统提交代码。这会让软件能一直保持在集成以后的可工作状态。你的软件会一直被测试,因为每次提交代码时,持续集成服务器就会从代码主干上运行自动测试。这会减小因重构引起的大规模合并导致冲突的可能性,
  • 为了确保提交代码时不破坏已有的应用程序,有两个实践非常有效
    • 在提交代码之前运行测试套件。这个测试套件应该是一个快速运转(一般少于10分钟)且相对比较全面的测试集合,
    • 增量式引入变化。我们建议每完成一个小功能或一次重构之后就提交代码

2.2.3 使用意义明显的提交注释

  • 我们喜欢的一种注释风格是这样的:第一段是简短的总结性描述,接下来的几段描述更多的细节
  • 这个注释中还应该包括一个链接,可以链接到项目管理工具中的一个功能或缺陷,从而知道为什么要修改这段代码

2.3 依赖管理

2.3.1 外部库文件管理

  • 我们建议在本地保存一份外部库的副本(如果使用Maven,应该创建一个本地仓库,里面存放那些在你的公司中统一使用的外部库)。这样,你就总能再现构建过程

2.3.2 组件管理

  • 将整个应用软件分成一系列的组件进行开发(小型应用除外)是个不错的实践。这能让某些变更的影响范围比较小,从而减少回归缺陷。另外,它还有利于重用,使大项目的开发过程更加高效

2.4 软件配置管理

  • 应该以对待代码的方式来对待你的系统配置,使其受到正确的管理和测试

2.4.1 配置与灵活性

  • 更好的方法几乎总是先专注于提供具有高价值且可配置程度较低的功能,然后在真正需要时再添加可配置选项

2.4.2 配置的分类

  • 我们可以在构建、部署、测试和发布过程中的任何一点进行配置信息的设置。而且,我们也的确会在多个时间点对应用软件进行相关的配置
    • 在生成二进制文件时,构建脚本可以在构建时引入相关的配置
    • 在打包时将配置信息一同打包到软件中
    • 在安装部署软件程序时,部署脚本或安装程序可以获取必要的配置信息,或者直接要求用户输入这些配置信息
    • 软件在启动或运行时可获取配置
  • 一般来说,我们并不赞同在构建或打包时就将配置信息植入的做法

2.4.3 应用程序的配置管理

  • 在管理应用程序的配置这个问题上,需要回答三个问题
    • (1) 如何描述配置信息?
    • (2) 部署脚本如何存取这些配置信息?
    • (3) 在环境、应用程序,以及应用程序各版本之间,每个配置信息有什么不同?
  • 通常配置信息以键值对的形式来表示。1有时可使用系统提供的配置类型来有层次地组织这些配置项
  • 版本控制库可能是最容易的,只要将配置文件签入就可以了,而且你可以随时拿到任意时间点上的历史配置信息
获取配置信息
  • 管理配置最有效的方法是让所有的应用程序通过一个中央服务系统得到它们所需要的配置信息
为配置项建模
  • 无论你使用哪种方式来存储配置信息,放在源代码控制中的XML文件也好,或REST式Web服务中也好,都要能够满足不同的要求
    • 新增一个环境(比如一个新的开发工作站,或性能测试环境)。在这种情况下你要能为这个配置应用的新环境指定一套新的配置信息
    • 创建应用程序的一个新版本,通常需要添加一些配置设置,删除一些过时的配置设置。此时应该确保在部署新版本时,可以使用新的配置设置,但是一旦需要回滚时,还能够使用旧版本的配置设置
    • 将新版本从一个环境迁移到另一个环境,此时应该确保新环境上的新配置项都有效,而且为其设置了正确的值
    • 重定向到一个数据库服务器。应该只需要简单地修改所有配置设置,就能让它指向新的数据库服务器
    • 通过虚拟化技术管理环境。应该能够使用虚拟技术管理工具创建某种指定的环境,并且配置好所有的虚拟机
  • 在不同环境之间管理配置信息的一种方法是,把预期的生产环境中的配置信息作为默认配置,而在其他环境中,通过适当的方式覆盖这些默认值(确保你有预防措施,以防生产环境受到配置失误的影响)
系统配置的测试
  • 一是要保证配置设置中对外部服务的引用是良好的。最起码,要保证能够与所有的外部服务相连通
  • 二是当应用程序一旦安装好,就要在其上运行一些冒烟测试,以验证它运行正常

2.4.4 跨应用的配置管理

  • 在大中型组织中,通常会同时管理很多应用程序,最重要的任务之一就是,要为每个应用程序维护一份所有配置选项的索引表,记录这些配置保存在什么地方,它们的生命周期是多长,以及如何修改它们
  • 如果可能的话,运行每个应用程序的构建脚本时应该自动生成一份这类信息。即使无法做到这一点,也要把它记录在Wiki上,或其他文档管理系统中
  • 每个应用程序的配置项管理都应该作为项目启动阶段的一个议题,纳入计划当中

2.4.5 管理配置信息的原则

  • 我们要把应用程序的配置信息当做代码一样看待,恰当地管理它,并对它进行测试。应该考虑以下几个方面
    • 在应用程序的生命周期中,我们应该在什么时候注入哪类配置信息
    • 将应用程序的配置项与源代码保存在同一个存储库中,但要把配置项的值保存在别处
    • 应该总是通过自动化的过程将配置项从保存配置信息的存储库中取出并设置好,这样就能很容易地掌握不同环境中的配置信息了
    • 配置系统应该能依据应用、应用软件的版本、将要部署的环境,为打包、安装以及部署脚本提供不同的配置值。每个人都应该能够非常容易地看到当前软件的某个特定版本部署到各种环境上的具体配置信息
    • 确保配置信息是模块化且封闭的,使得对某处配置项的修改不会影响到那些与其无关的配置项
    • DRY(Don't Repeat Yourself )原则。定义好配置中的每个元素,使每个配置元素在整个系统中都是唯一的,其含义绝不与其他元素重叠
    • 最少化,即配置信息应尽可能简单且集中。除非有要求或必须使用,否则不要新增配置项
    • 避免对配置信息的过分设计,应尽可能简单
    • 使用冒烟测试来诊断依赖于配置项的相关功能是否都能正常工作

2.5 环境管理

  • 在做应用程序的环境管理时,我们需要记住的原则是:环境的配置和应用程序的配置同样重要
  • 在The Visible Ops Handbook一书中,其作者把手工配置的环境称作“艺术作品”
  • 需要考虑的环境配置信息如下
    • 环境中各种各样的操作系统,包括其版本、补丁级别以及配置设置
    • 应用程序所依赖的需要安装到每个环境中的软件包,以及这些软件包的具体版本和配置
    • 应用程序正常工作所必需的网络拓扑结构
    • 应用程序所依赖的所有外部服务,以及这些服务的版本和配置信息
    • 现有的数据以及其他相关信息(比如生产数据库)
  • 其实高效配置管理策略的两个基本原则是
    • (1) 将二进制文件与配置信息分离
    • (2) 将所有的配置信息保存在一处

2.5.1 环境管理的工具

  • 在以自动化方式管理操作系统配置的工具中,Puppet和CfEngine是两个代表

2.5.2 变更过程管理

  • 最后要强调的是,对环境的变更过程进行管理是必要的。应该严格控制生产环境,未经组织内部正式的变更管理过程,任何人不得对其进行修改

2.6 小结

  • 配置管理是本书其他内容的基础。没有配置管理,根本谈不上持续集成、发布管理以及部署流水线。它对交付团队内部的协作也会起到巨大的促进作用
  • 我们建议为下面的内容制定出一个保存基线和控制变更的策略
    • 应用程序的源代码、构建脚本、测试、文档、需求、数据库脚本、代码库以及配置文件
    • 用于开发、测试和运维的工具集
    • 用于开发、测试和生产运行的所有环境
    • 与应用程序相关的整个软件栈,包括二进制代码及相关配置
    • 在应用程序的整个生产周期(包括构建、部署、测试以及运维)的任意一种环境上,与该应用程序相关联的配置
本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-09-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 yeedomliu 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 第 2 章 配置管理
    • 2.1 引言
      • 2.2 使用版本控制
        • 2.2.1 对所有内容进行版本控制
        • 2.2.2 频繁提交代码到主干
        • 2.2.3 使用意义明显的提交注释
      • 2.3 依赖管理
        • 2.3.1 外部库文件管理
        • 2.3.2 组件管理
      • 2.4 软件配置管理
        • 2.4.1 配置与灵活性
        • 2.4.2 配置的分类
        • 2.4.3 应用程序的配置管理
        • 2.4.4 跨应用的配置管理
        • 2.4.5 管理配置信息的原则
      • 2.5 环境管理
        • 2.5.1 环境管理的工具
        • 2.5.2 变更过程管理
      • 2.6 小结
      相关产品与服务
      数据库
      云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
      领券
      问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档