传统人工部署测试环境的流程
包括测试、UAT、准生产、压力测试等不同阶段
等待时间 执行时间 2 周 20 小时 2周 15 小时 1周 30 小时 1 小时
申请环境
服务台填写工 单
部署环境
克隆虚拟机
验证环境
验证防火墙
QA 测试
从生产数据库 恢导入经过清 洗的数据
归档环境
备份环境
研发团队 Check in 新代 码
使用一致的工具 • Same tool set between Dev & Ops
DevOps
跨不同职能团队和技能 • Dev, QA, Ops as Single Team • Mix of skills Dev/QE & Ops
开发 运维
部署流水线 • Automated Pipeline for full Deployment Lifecycle 自动分阶段发布 • Rolling releases – small to large environments
研发
Integrated Dev. Env. Build & Integration Package & Repository
UAT测试
预生产
生产
Test Automation
Continuous Integration
代码开发& Check-in
Build, Integration 与 测试
版本管理
为了解决不断升级的问题，Citi Bank“S.W.A.T.小组”定位出 了最迫切需要突破的瓶颈两个瓶颈：应用交付与合规监管
/sites/erikaandersen/2012/09/04/5-practical-ways-to-break-through-innovation-bottlenecks/
发布团队 Promote builds based on gating rules and policies.
运维团队 Deploy into production
开发测试云的愿景：
自动化开发测试环境流程
现有人工的流程：
未来建议的自动化流程：
• 总耗时：4 星期 • 总人工：30 小时（FTE） • 结果：不一致的测试环境
网络配置
验证OS配置
运行测试案例
关闭机器
Linux 团队
VM 团队 网络团队 研发团队 QA 基础架构团队 QA 测试团队 安全团队
软件安装
验证应用配置
记录软件Bug
配置应用
-
5周 / 一次部署
8
开发测试云的愿景：
加速软件开发生命周期（从代码到交付的不同阶段）
连续的交付平台：更频繁的发布、更少的软件缺陷、更快发现软件缺陷
• 总耗时：15 分钟 • 总人工：0.0001小时（FTE） • 结果：可重用的标准测试环境
10
DevOps为开发测试云提供了可选的方向
• 频繁发布新应用、 新版本 • 满足业务要求 • “小步快跑”式 • 保持生产环境稳定
运维
开发
• 降低风险，发布不
要太频繁 • 应用上线通过规范 的移交流程
的应用升级
. . . 但是后续的发布流程怎么办？
开发变快了，但应用依旧延迟交付
敏捷开发模式下的发布流程
研发希望应用 快速推送到生产
运维希望稳定、 尽量少变更
测试
UAT
准生产
压力测试
生产
开发
Continuous Integration
实现的 敏捷软件开发
频繁发布应用 的小版本
发布流程依然 是手工完成
敏捷带来的新的风险
部署与测试
推送与治理
生产部署
开发人员 IDE Check-in\Out Unit test
Build & Release Build scripts, ase Repository Mgmt Tagging Builds
QE Provisioning or updates Different environs and teams, UAT, staging…
VMWare 开发测试云 平台架构
云计算推动开发测试的革新
如何快速、可靠地获取新的业务能力
花旗银行的一个真实案例： 这家覆盖全球的金融公司在酝酿一个新的业务模型，可能对该行的某些核心业 务造成颠覆式的改造。新模型引入了多种新的技术，包括“以客为先”的设计 原则，以及以加强银行和客户之间联系的流程创新。 但是花旗内部的多个瓶颈也让这项新的业务模型面临了不少风险，包括资金的 获取，新技术的部署，新团队的训练，以及获得合规部门的同意。
应用交付延迟、风险太高
传统发布流程
应用每隔一到三个月 发布到生产环境 开发 测试 UAT 准生产 压力测试 生产
累计大量的变更需要
应用到生产环境 许多应用变更绑定到 一次发布中
4
更快的应用交付、更好的质量、更低的成本
运用Continuous Integration的敏捷开发
Development
集成测试环境 源代码版本控制 Build 与 集成
代码打包 与 Repository
测试自动化
Continuous Integration 的原则
• • • • 研发人员频繁地check-in代码 解决任何代码变更带来的应用不可用问题，是最高优先级 自动化Build与测试流程 版本控制无处不在
每次变更后确保软件 均是可用的
敏捷开发模式下的发布流程
缺少方案将发布Build与测试结果，以及部署环境连接起来
安装不正确的应用版本 可能会破坏测试环境
发布流程中不同阶段的配置与应用版本的差异， 让生产环境中的问题更难定位
测试 开发
UAT
准生产
压力测试
生产
Continuous Integration
实现的 敏捷软件开发
如果不同发布中有依赖关系的变更无法追踪到， 可能会破坏端到端的业务流程测试
Release 1 • Feature 1 • Feature 2
为生产环境改良研发流程 • Early creation of ops artifacts in Dev/QE Stages
自动发布 • Automate, automate, automate – Build, Release
Release 2
• Feature 3 • Feature 4
Release 3
• Feature 5 • Feature 6
11
a. 自动从版本控制工具获得代码、脚本、测试数据等 b. 尽可能地自动集成、部署，在准生产环境中验证代码 c. 将经过验证的Build部署到生产环境，验证新应用