持续交付学习笔记

原创 2018年04月16日 14:12:50

1. CD介绍

1.1 要点

什么是CD? 以一种可承受的方式,安全、快速地落实变更的能力 
为什么要CD? 无痛release,降低风险;加速进入市场;提高软件质量和稳定性;减少软件开发的成本;让客户和员工开心;快速获得反馈 
许多Agile项目的问题,在原来的water fall中增加了scrum: (PMO+finance)研究+批准->设计+计划; (‘Agile’ team迭代)分析、开发、测试+演示; (Centralized QA)集成+QA->(IT运维)Release&运维。最后一公里的集成测试和Release仍然痛苦, CD就是要铲除最后一公里,每个迭代(甚至在迭代之内)都为用户产出产品 
amazon.com 2010年时,在工作日平均11.6秒做一次部署,最高峰一小时做了1079次部署,平均每次部署10000台,最高每次部署30000台。 
要点:提升质量;每次处理更小的单元;重复的工作交给电脑,人来解决问题;持续改进;人人需对产出负责

1.2 价值

拥有更高效、能快速变化IT能力的组织在市场上更有竞争力。 
你的组织多长时间能将一个单行代码的变更部署到生产环境?你们可以以一个可重复、可靠的基础完成部署 
Lead time: 能多快还原一个服务?能多快发布一个严重问题修复?能多快验证一个特性有价值? 
使用了简化、自动化、降低风险的流程,可以保证更频繁的Release。 
小的变更,易于判断引起问题的原因 
判断价值 -> 假说驱动Delivery:我们相信为XXX开发的YYY特性,将达到ZZZ目标;如果我们能看到市场上XXX信号,我们将知道我们成功 
“Online experimentation at Microsoft”,仅有1/3的新特性改进了核心度量

1.3 要素

Architecture 要求系统的可测试性和可部署性;可以快速廉价的在开发机上完成完整测试是否可以Realease,无需复杂的部署流程。 
Patterns & practices 
Collaboration 
要素:配置管理,持续集成,自动化测试 
高IT表现(DevOps):代码、APP配置和系统配置都在一个版本控制系统,高吞吐(自动化)高稳定性(快速回滚);从日志和监控系统获得失效警告;开发每天将代码merge到主干;开发将大的特性分解成小的、增量的变化;开发和运维团队交流产生双赢结果 
莫等到开发结束后才做测试,Check in代码之前就要做测试;每个人都对质量抱有责任,开发、测试、运维 
由开发工作站、橡皮鸭和铃构成的简单CI系统。在本地开发->在本地构建并测试->从主干抓取代码并合并->在本地构建并测试->获取橡皮鸭->推送并在服务器构建并测试->(成功)归还橡皮鸭并按铃->(失败)如果短暂的几分钟修复不了,则在主干上回滚代码 
不同种类的测试: 
- 自动化:UT, 组件测试,系统测试;功能接受测试 
- 手工:演示,易用性测试,探索测试 
- 自动化/手工:非功能测试(容量,安全,可用性) 对于架构的验证,易尽早开展

1.4 部署管道(Deployment Pipeline)

部署管道示意
图中是一个简化版的,部署管道可能很复杂。 
自动化测试要尽可能块,尽快反馈测试的结果 
这里写图片描述 
提交阶段:每次check-in都执行;创建release备选;失败则立即修复 
接受阶段:package放在artifact repo(如nexus),而非版本控制中;在类生产环境中做端到端测试,通过提交测试即触发;失败则立即修复 
手工阶段:UAT, staging, integration, production;通过按钮流程自服务的部署;推送系统 
部署管道经验之谈:仅一次构建你的包,放入repo中后用于各阶段测试直至生产;用同样的脚本、流程、方式部署所有的环境;部署后进行冒烟测试;保持环境一致,拓扑,硬件,系统,软件;如果中间有环节失败了,停止管道。

1.5 案例:HP LaserJet固件部门

除了构建Web服务,CD同样可以用于传统的安装型软件、固件 
问题:位于3个国家超过400位工程师,固件部门已经多年on the critical path,已经尝试过多种方案。 
08年时,提交代码到trunk需1周,每天1/2个build,全回归手工测试需6周 
Re-architecture: 减少硬件变种,创建一个单一package,实现CI,投资于广泛的测试自动化,创建用于自动化的仿真器 
Developer做Demo时即问,代码是否已经合并到了trunk?是否已经有自动化测试? 
持续部署案例 
到2011年时,创新的时间由5%升级到40%。开发成本降低40%,同时开发的程序增长了140%,每个程序的开发成本降低了78%,创新的资源增加了8倍

版权声明:本文为博主原创文章,转载时请注明出处 https://blog.csdn.net/gongxsh00/article/details/79959917

什么是持续交付

作者:Sam Guckenheimer Continuous Delivery (CD) is the process to build, test, configure and deploy ...
  • kasteluo
  • kasteluo
  • 2017-06-19 09:17:02
  • 1058

高效持续交付的7大原则

持续交付不仅仅是一个很好的想法,就像每一个使用敏捷方法的人会告诉你的,它已经迅速的成为了必须品。它很重要,然而,不论是你正在将他引入到你的组织当中,还是想要优化你的持续交付方法,你都需要使用正确的持续...
  • steelren
  • steelren
  • 2017-06-09 22:52:14
  • 605

持续交付的架构成熟度模型

随着云和容器技术的发展,大家对DevOps和CI/CD的重要性有了更深入的认识。今天我们就讨论一下架构设计如何更好的支持CI/CD。 什么是持续集成,交付和部署(CI/CD) Martin Fow...
  • github_39335046
  • github_39335046
  • 2017-06-29 10:54:29
  • 513

大型系统持续集成持续交付解决方案及案例

全文链接
  • bystarlight
  • bystarlight
  • 2017-06-06 13:53:05
  • 329

利用docker开启持续交付之路

持续交付即Continuous Delivery,简称CD,随着DevOps的流行正越来越被传统企业所重视。持续交付讲求以短周期、小细粒度,自动化的方式频繁的交付软件,在这个过程中要求开发、测试、用户...
  • xuguokun1986
  • xuguokun1986
  • 2016-06-28 21:55:21
  • 1400

持续交付之自动化构建

前言:        十年前,敏捷软件开发方法在国内还少有人知,现在却成主流。持续集成作为一个敏捷开发的最佳实践,近年来也被广泛接受。然而,作为企业来讲,除了要分析业务开发模型和组织结构是否适合用敏...
  • xucl77
  • xucl77
  • 2012-12-11 13:40:38
  • 1076

持续交付之二——配置管理

第二章 配置管理1. 引言 定义: 配置管理是指一个过程, 通过该过程, 所有与项目相关的产物, 以及他们之间的关系, 都被唯一的定义, 存储, 检索和修改 2. 使用版本控制2.1. 对所有内容...
  • RO_wsy
  • RO_wsy
  • 2016-05-07 08:39:34
  • 1444

什么是持续集成?持续交付?持续部署?

一、概念持续集成指的是,频繁地(一天多次)将代码集成到主干。它的好处主要有两个。(1)快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。 (2)防止分支大幅偏离主干。...
  • zkaipmoo
  • zkaipmoo
  • 2016-09-22 10:33:59
  • 808

持续交付是什么,是种什么能力

理解用我们如今的白话来描述最简单的就是,你提交一行修改某个bug的代码,发布系统会按照流程自动化的做完一系列的检查,然后发布一个版本到生产环境。这样用户在最短的时间内可以拿到修改的结果。引用CI CD...
  • figo645
  • figo645
  • 2018-03-13 17:19:17
  • 22

携程持续交付平台的演进、变革与展望

本文转自:https://mp.weixin.qq.com/s/HqyJQMRHh2KrdFmNtPbX3w 越过山丘:...
  • windanchaos
  • windanchaos
  • 2018-01-23 14:51:59
  • 245
收藏助手
不良信息举报
您举报文章:持续交付学习笔记
举报原因:
原因补充:

(最多只允许输入30个字)