持续交付36讲
王潇俊
携程系统研发部总监
立即订阅
7125 人已学习
课程目录
已完结 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讲
登录|注册
08 | 测试环境要多少？从现实需求说起
王潇俊 2018-07-21
在整个持续交付生命周期中，测试环境的易用程度会直接影响软件的交付速度，但因为以下两点，它又是最被容易忽略的一环。
我们总是把环境理想化，忽略了其管理的难度；
我们也很少设立专职的环境管理员，导致环境长期处于混乱状态。
通常，我们在项目初期并不会关注测试环境的问题，然而在回顾时却发现在环境问题上浪费的时间非常惊人：硬件资源申请困难，测试环境配置繁琐，测试应用更新困难，基础设施稳定性差，服务调用异常，多项目并行造成互相干扰等等问题。
而不管你是开发人员还是测试人员，相信你都或多或少地碰到过这些问题。
在接下来的《环境管理》系列文章中，我会和你聊聊构建一整套好的测试环境的关键点以及具体实施方案。今天，我就先跟你说说和测试环境相关的两个问题：
测试环境的结构一般是怎样的？
什么才是好的测试环境？
互联网公司测试环境的结构
当公司规模较小时，测试环境的维护相对容易。开发和测试共用一套数据库缓存等基础设施，因为应用数量不多，开发环境可以是单机的，无论是手动或半自动化的更新测试环境的应用，花费的时间都还在可接受范围内。
这时，公司环境的结构很简单，分为开发环境，测试环境，生产环境即可。
但实际上，我看到的大多数公司的研发过程及配套环境并没有这么简单，一般都会存在 5 套以上的大环境以及更多的子环境，每个环境的机器数量可能有数十台甚至更多。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《持续交付36讲》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(16)
齐涛-道长 置顶最痛苦的是防火墙问题。公司只有一套Jenkins在生产环境网段，公司策略又不允许生产环境访问测试环境，于是乎目前还遗留的仅能访问的个别测试机器极其宝贵，后续一旦这些机器被换掉，那就真是完全隔离了。另外公司的网络策略现在限制不允许开22端口，于是乎我可以预见到不远的未来我们将从Jenkins自动化部署转变为全部自己动手部署了作者回复: 你提的问题很好，我也确实忘了这一块的内容。其实比较好的网络划分是为持续交付或部署系统之类的工具划分出专用的工具网段，此网段可同时访问测试和生产，反之则是受控的。虽然从网络管理角度来说会复杂一些，但结构和用途就更清晰了
2018-07-22- Xiangjun如何利用开源红利，快速搭建一套持续交付平台。
在这一部分，我会手把手地，带你真正去搭建一套最小集合的持续交付平台。
什么时候讲干货？作者回复: 哈哈，其实那些只是“知其然”，还是要看“知其所以然”的带问号的几讲呢
2018-07-21 4 
pein感觉讲的比较皮毛，问题提的很尖锐，比如多个开发团队并行开发的话环境怎么保证，但是说的方案只是五个串行环境的方案，并不能解决之前作者提出的问题，还是希望作者可以多讲一些百度查不到的信息作者回复: 环境问题会有多讲，作为第一讲，力求先把问题解释清楚，后续自然会有更清晰的解答。也可以关注一下全部目录哦，定位自己特别关注的部分，毕竟读者的背景，经验都会有所不同，还是需要照顾全面：）
2018-07-23 2
王保安请问老师：预生产环境也是连接生产环境的数据库吧，那发布预发环境的时候，需要执行SQL，岂不是影响了生成环境。这个问题怎么解决呢。2019-08-02
春之绿野环境太乱了，无数的线纠缠在一起，光看看就崩溃。
测试工具不是跨平台的，只能windows 上运行，不能用docker做成自动化可恢复的。有了问题不能无脑重装。
环境太脆弱了，今天这个线接触不好了明天那个接触不好了，虽然就是重新插拔，但排查费时间啊。
没有文档，对新手比较痛苦。2019-06-08
黄无由老师，请问回归测试在哪个环境？2019-04-11 1
hyeebeen比较痛苦的问题是：多套测试环境之间的同步，还有对外有第三方接口依赖的时候的联调。2018-12-29
MsgR一般我只做四套环境。每套环境都是应需求而生，统一的本地开发环境，环境与线上一致的的测试场景，使用环境和数据与线上一致的预发布环境，生产环境。按照老王的分法，我们应该是把验收测试与预发布环境合一了。作者回复: 环境的多少主要还是遵循研发需求，只有最适合，没有最好
2018-10-28
仗剑走天涯而每个项目组的同学在测试时，都希望测试过程中的关键依赖应用是可以被独占的，版本是固定的，不会被其他项目组干扰。
这段似乎不足以说明为什么需要一套功能测试环境啊2018-08-03
张飞洪王总，请问SaaS用微服务架构合适吗？作者回复: 微服务，说到底就是为了解耦，把复杂问题简单化，只要是这个目标，就是合理的了
2018-07-25
旭东现在测试环境和开发环境的网络互通，经常因为开发的配置问题导致与测试的服务一起启动，造成服务被掳走到开发环境。作者回复: 下一讲中就会讲到解决方案
2018-07-24
叶子要部署这么多不同的环境，在开发资源上会不会需要投入的成本如何控制呢作者回复: 下一讲就会提到成本和如何做的问题
2018-07-23
不需往后看老师你好，对于 java 这块的自动化测试一直有个困惑 - 即，如何组织测试代码、如何管控单元测试/集成测试。
比如单元测试和集成测试的目录结构是什么样的？
再比如集成测试我知道通常有两种组织方式，一种是和单元测试代码放在一起，通过文件夹以及类名后缀来和单元测试区分，另一种是把集成测试独立为一个 maven 模块，但是这样会存在不同环境模块依赖问题（比如ide 下没问题，但测试环境下报依赖找不到的错误）。到底哪种组织方式更好？
再比如单元测试和集成测试具体如何和持续集成交织在一起？这块是不是后面会讲到 🙈🙈
希望老师能指点一二，感谢作者回复: 毕竟不是专门讲测试，讲不到很透，但一般我们是分开目录结构的，单元测试和集成测试将会在两个隔离环境进行，而依赖问题还是要看具体案例用标准的方式来解决，当然集成测试还要善用mock
2018-07-23- Edward目前多套环境的隔离，意味着终端也要配置5套切换的环境，然而这种推动难度很大
作者回复: 移动client的话，可以通过配置不同Gateway来解决
2018-07-23 - 不需往后看都是干货，支持老师。
之前自己摸索过持续集成/交付相关的思路，分支策略和测试环境是重中之重，没有分治策略和测试环境，持续集成根本无从谈起。
希望没太有耐心的那几位同学，认真看看之前的内容，相信对后面课程的学习会有很大帮助。2018-07-22 
白天不懂爷的黑比如java环境和线上不一致，程序部署目录和日志和线上不一致。我的解决办法是复制一套线上环境的salt脚本，使用lshell工具限制测试同学能执行的命令和能进入的目录，避免测试同学随意更改服务器环境。然后把测试环境的jenkins权限开放给对应项目的同学。或者使用docker吧2018-07-21
收起评论