持续交付36讲
王潇俊
携程系统研发部总监
立即订阅
7090 人已学习
课程目录
已完结 41 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 量身定制你的持续交付体系
免费
基本概念 (3讲)
01 | 持续交付到底有什么价值?
02 | 影响持续交付的因素有哪些?
03 | 持续交付和DevOps是一对好基友
配置管理 (4讲)
04 | 一切的源头,代码分支策略的选择
05 | 手把手教你依赖管理
06 | 代码回滚,你真的理解吗?
07 |  “两个披萨”团队的代码管理实际案例
环境管理 (6讲)
08 | 测试环境要多少?从现实需求说起
09 | 测试环境要多少?从成本与效率说起
10 | 让环境自己说话,论环境自描述的重要性
11 | “配置”是把双刃剑,带你了解各种配置方法
12 | 极限挑战,如何做到分钟级搭建环境?
13 | 容器技术真的是环境管理的救星吗?
构建集成 (5讲)
14 | 如何做到构建的提速,再提速!
15 | 构建检测,无规矩不成方圆
16 | 构建资源的弹性伸缩
17 | 容器镜像构建的那些事儿
18 | 如何做好容器镜像的个性化及合规检查?
发布及监控 (6讲)
19 | 发布是持续交付的最后一公里
20 | Immutable!任何变更都需要发布
21 | 发布系统一定要注意用户体验
22 | 发布系统的核心架构和功能设计
23 | 业务及系统架构对发布的影响
24 | 如何利用监控保障发布质量?
测试管理 (3讲)
25 | 代码静态检查实践
26 | 越来越重要的破坏性测试
27 | 利用Mock与回放技术助力自动化回归
持续交付平台化 (3讲)
28 | 持续交付为什么要平台化设计?
29 | 计算资源也是交付的内容
30 | 持续交付中有哪些宝贵数据?
持续交付移动App (3讲)
31 | 了解移动App的持续交付生命周期
32 | 细谈移动APP的交付流水线(pipeline)
33 | 进阶,如何进一步提升移动APP的交付效率?
实践案例 (4讲)
34 | 快速构建持续交付系统(一):需求分析
35 | 快速构建持续交付系统(二):GitLab 解决代码管理问题
36 | 快速构建持续交付系统(三):Jenkins 解决集成打包问题
37 | 快速构建持续交付系统(四):Ansible 解决自动部署问题
特别放送 (2讲)
持续交付专栏特别放送 | 答疑解惑
持续交付专栏特别放送 | 高效学习指南
结束语 (1讲)
结束语 | 越痛苦的事,越要经常做
持续交付36讲
登录|注册

11 | “配置”是把双刃剑,带你了解各种配置方法

王潇俊 2018-07-28
很多人分不清配置和配置管理,但其实它们是完全不同的概念。
配置管理: 是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。 它的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期的各个阶段都能得到精确的产品配置信息。
配置: 是指独立于程序之外,但又对程序产生作用的可配变量。也就是说,同一份代码在不同的配置下,会产生不同的运行结果。
从上面的定义中,你可以看到配置和配置管理有着本质上的不同:配置管理服务于软件研发过程,而配置则服务于程序本身。
作为一名程序员,开发时经常要面对不同的运行环境:开发环境、测试环境、生产环境、内网环境、外网环境等等。不同的环境,相关的配置一般不一样,比如数据源配置、日志文件配置,以及一些软件运行过程中的基本配置等。
另外,你也会遇到一些业务上的,以及逻辑上的配置。比如,针对不同地域采取不同的计费逻辑,计费逻辑又要根据这些地域的需要随时调整。
如果我们把这些信息都硬编码在代码里,结果就是:每次发布因为环境不同,或者业务逻辑的调整,都要修改代码。而代码一旦被修改,就需要完整的测试,那么变更的代价将是巨大的。
因此,我们往往会通过“配置”来解决这些问题。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《持续交付36讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • 有道测试组
    apollo 这个看着不错,我们可以看看
    我们一般把配置分为两类, 一类是环境相关的全局配置,另一类是程序相关的局部配置。
     局部配置一般放在代码包里跟着代码走, 一般情况下,全局配置是部署的时候需要提供的,比如指定部署的机器, 端口等,代码配置一般是不需要变更的,如果变更,配置中心指定要变更的项目,推到机器上, 或者本地有配置agent 服务的话,也能定期pull 配置中心的该变更项 。
    2018-12-26
    2
  • Tank
    阿波罗相比disconf有哪些优势呢

    作者回复: 可以参考以下文档
    https://github.com/ctripcorp/apollo/wiki/FAQ#10-apollo和disconf相比有什么优点

    2018-07-29
    2
  • 陈浩林
    请问,像nginx,以及docker这样的,是不是都可以用配置中心来管理配置?
    那我理解的,就是只要是文件形式存在于应用程序里的配置,都可以修改吗?

    作者回复: 也不能这么说,我们使用配置中心主要是为了解决业务逻辑的配置,需要中间件配合,你提到的有些系统本身很完整比如k8s,自己有配置方案,而nginx是否可以使用你选择的中间件才是问题,当然以这个思路做二次开发都不是问题

    2018-09-25
    1
  • 王保安
    请教老师个问题。
    我们测试环境有五套,例如叫:test1、test2、test3、test4、test5。
    现在是这五套环境用的五个IDC,就是每个环境不同的配置集群。可是这五个环境的配置项,大部分是相同的,只有四五个是各环境不同的。
    有没有办法,让五个环境的某些配置项共用一套配置,另外一些配置项再加载不同的配置集群。
    2019-10-29
  • 陈sir
    你好 俊哥 好亲切 我曾在携程短暂的待过一段时间 现在遇到一个问题:在线上发布时 我们不止一次的把测试环境的地址配置到了线上,请问针对这个问题 你有什么好的建议吗?

    作者回复: 优先使用Apollo这样的配置中心,数据结构支持一个key分属不同环境的不同value,读取时根据环境值获取

    2019-08-07
  • 华华
    按照《持续交付》书中的说法,把每个环境的配置文件作为代码在git中维护是最好的办法!

    作者回复:
    我个人认为这种说法已经过时了。可以参看专栏中的相关内容。代码版本和配置应该解耦,否则会产生两种结果,一,不同环境的版本不对应;或者版本冗余

    2018-12-22
  • 付盼星
    apollo内置了高可用注册中心,为什么不开放端口,也能当注册中心来用?

    作者回复: Apollo有一个自用的注册中心功能,确实可以用,但毕竟不是专门做这块的服务,功能就较简单,有些能力可能也是缺失的

    2018-08-12
  • 海水
    配置中线的权限问题怎么解决?比如第三方的key,和 普通配置 如果让不同的人员管理不同的配置?

    作者回复: 配置本身可以属于不同的category,对这层做权限即可,当然你问一个key是否可以属于多个category,那就看你的具体设计了

    2018-07-30
  • 祺超
    以Java为例,JVM参数,应用的端口等等应该放在哪里呢?

    作者回复: 这是个好问题,jvm参数有很多特殊性,包括冲突配置等,目前我们的想法是独立一套单独的服务做这块,服务的生命周期在编译打包。但还没完全实现

    2018-07-30
  • 刘京城
    谢谢!这一节的内容对我们项目现在正有用!我们项目现在有一些与业务强关联的硬编码,而且有上百处,现在要对不同的客户即不同的生产环境进行部署,所以必须把硬编码改成配置,请问这种情况适合用配置中心来进行管理吗?期待您的回复

    作者回复: 可以再看一下上一讲的内容,联系起来使用配置中心,是很合适的解决方案

    2018-07-28
收起评论
10
返回
顶部