极客时间持续交付36讲学习笔记Word文件下载.docx
《极客时间持续交付36讲学习笔记Word文件下载.docx》由会员分享，可在线阅读，更多相关《极客时间持续交付36讲学习笔记Word文件下载.docx（28页珍藏版）》请在冰豆网上搜索。
・它就和Java中的不可变类完全相同：
类实例一旦创建,就无法变更，而可以
变更的是指向实例的引用。
・对但可的包、配置文件、软件应用和数据，都不做CRUD（创建、替换、更
新、删除）操作。
・对于已经存在的斟出设施,不再在其上创造任何新的事物
•1•构建一个新的基础设施；
•2•测试新的基I出设施是否符合需求；
•3将引用指向这个新的基础设施；
•4•保留原有基础设施以备回滚。
・不可变（Immutable）的前提是无状态。
・容器技术解决的问题（仅仅通过发散和收敛是解决不了的）
•顺序问题
•频率问题
•蝴蝶效应
・Immutable的衍生
•黄金映像，指的是将绝大部分不变的斟出设施（包括操作系统、大多数软件、基本配置等）,包含在映像内，只留很少一部分变更通过脚本执行解决
•VDI（虚拟桌面），指的是操作系统运行在后端的服勢器上,用户只使用属于他自己的虚拟桌面，无法改变后端的系统内容；
•PhoenixServer,指的是完全被破坏的服务器，能够从灰烬中自动进行恢复；
•基础设施即代码,指的是把基^设施的构建以代码的方式组织起来，从而通过运行代码可以完全构建出你想要的全部基础设施。
o用户体验角度落地发布系统
・1张页面展示发布信息，且仅有1张页面,展示发布当时的绝大多数信息、数据和内容,这个页面既要全面，又要精准。
・2个操作按钮简化使用，即页面上除了"
回滚"
按钮常在外,最多同时展示2个操作按钮。
目的是要降低发布系统的使用难度，做到"
谁开发,谁运行"
。
・3种发布结果，即成功、失败和中断状态，目的是简单、明了地显示用户最关
心的发布结果。
・4类操作选择，包括开始发布、停止发布、发布回退、发布重试,目的是使状态机清晰明了。
・5个发布步骤,即markdown、download,install,verify和markup。
这
里需要注意到的是，verify这步包含了预热，由于耗时往往比较长，一般采用异步的处理方式。
•单个实例的发布过程,分为5个步骤：
markdown:
为了减少应用发布时对用户的影响,所以在一个实例发布前,都会做拉出集群的操作，这样新的流星就不会再继续进入了。
download:
这就是根据版本号下载代码包的过程；
install:
在这个过程中,会完成停心艮勢、替换代码、重启服务这些操作；
verify:
除了必要的启动预检外，这一步还包括了预热过程；
markup:
把实例拉回集群,重新接收流臺和请求。
・6大页面主要内容，包括集群、实例、发布日志、发布历史、发布批次、发布操作，来统一、简洁而又详细呈现发布中和未发布时的各种信息。
・三个原则
•信息直观,聚合
•操作简单，直接
•步骤与状态清晰
O发布系统架构
・要求
•清晰
•健壮
•低耦合
•分布式、高可用、易扩展
・注意点
•每台服勢实例上的发布脚本一旦产生则不再修改，以达到不可变模型的要求；
•发布引擎和SaltMaster之间采用异步通信，但为增强系统健壮性，要有同步轮询的备案；
•面对频繁的信息获取，要善用缓存，但同时也一走要慎用缓存，注意发布信息的新鲜度。
技术点
•布系统的核心模型主要包括Group、DeploymentConfig,Deployment、DeploymentBatch,和DeploymentTarget这5项
•携程之所以这样设计,是因为group这个对象直接表示一个应用的_组实例,这样既可以支持单机单应用的部署架构,也可以支持单机多应用的情况。
•借助于Celery分布式任务队列的Chain函数，发布系统将上述的Markdown.Download.Install.Verify,Markup五个阶段走义为—个完整的链式任勢工作流，保证一个Chain函数里的子］壬务会依次执行。
•堡垒就是预发布实例,它就是生成集群的一个子集，但发布后，首先不接入外部正式流星，做自测用，自测通过后才接入生产流呈
•除堡垒批次外的每个发布批次均采用了QuickandDirty的发布方式，即不管成功或失败，优先尝试把版本发布完，继续执行下个发布批次，后续再解决个别目标服务器发布失败的问题。
•刹车机制,即在每个批次开始发布任勢前,系统会根据用户设置的单个批次可拉出上限比,进行失败率的计算与控制。
发布时,—旦达到这个失败率，立即中断当前发布，从而保护QuickandDirty发布方式
•各个机房艇了发布包专用的存储系统，实现了类似CDN的功能，编译和打包系统在彳壬何一个写入点写入发布包,都会尽快同步到各个IDC及各个独立存储中,这样真正发布时,服务器只需从本IDC或本网段做下载。
•降级机制可以保证发布系统做到，只有部署包存在,就能恢复服勢。
•子主题
•点火
■优化
O我们借助于VI（ValidateInternal）框架中间件，实现了Verify过程的自动化,我们把这个过程形象地叫作"
点火"
单机多应用IIS架构的弊端
o由于ns的设计问题,不同虚拟目录之间可能存在共用应用程序池的情况,即多个应用运行在同一个进程下,导致任何一个应用的发布都可能对其他的关联应用造成影响。
o解决这个问题采用的方案是,去除根目录的被继承作用，默认每个虔拟目录就是一个应用,并且每个虚拟目录的应用程序池独立。
而每个虚拟目录以应用的名称命名，保证单机上不会发生冲突。
单机单应用的优势
O单机单应用不需要考虑分配服务端口的问题,所有的Web应用都可以使用同一个统一端口（比如,8080端口）对外服勢
o单机单应用在故障排除、配置管理等方面同样具有很多优势。
—言以籲之,简单的才是最好的
全星发布的优势
o增星发布对回滚非常不友好，你很难确走增臺发布前的具体内容是什么。
如果你真的要确走这些具体内容的话，就要做全版本的差异记录,获取每个版本和其他版本间的差异,这是一个巨大的笛卡尔积,需要耗费大呈的计算资源，简直就是得不偿失
O我的建议是,全星发布是互联网应用发布的最好方式。
使用标志位
O携程在设计系统时,用不同的标志位来标识发布系统、运维操作、健康检测，以及服务负责人对服勢的Markup和
Markdown状态。
4个标志位的任何一个为Markdown都代表暂停服勢,只有所有标志位都是Markup时,服务中心才会向外暴露这个服勢实例。
O解决多角色对服勢markup和Markdown的冲突问题
对于生产环境，发布结束才是最危险的时刻
监控分类
•用户侧监控
o访问速度和结果
•网络监控
oCDN与核心网络
•业务雌
o关注核心业务扌旨标的波动
•应用监控
o服务调用链
•糸统监控
o即基础设施、虚拟机及操作系统
用户侧监控
•通过打点或者走期日志收集
•端到端监控
O访问呈
O访问成功率
O响应时间
O发包回包时间
O不同维度：
地区、运营商、App版本、返回码、网络类型等
•移动端日志
•備表现雌
oCPU
O内存
O
O卡顿、白屏
O堆栈分析
•唯一用户ID监控
・网络监控
•网络监控并不需要做到太细致和太深入，因为大多数网络问题最终也会表现为其他应用层面的故障问题。
但是,如果你的诉求是要快速走位rootcause,那就需要花费比较大的猜力去做好网络监控了
•公网
•内网
・监控无［去处理的两种情况
•累积效应,即系统异常需要累积到一走呈后才会表现为业务异常；
•业务的阴跌，这种小幅度的变化也无法在业勢监控上得到体现。
・三个重要问题
•测试环境是否监控?
o测试环境的监控需要视作用而走，如果不能帮助分析和定位问题,则不需要很全面的监控；
•发布后监控多久？
O—般发布后,我建议继续坚持监控30分钟，把这个流程纳入发布流程中；
•如何确走异常是由发布引起的？
o完整的运维事件记录体系，可以帮你走位某次故障是否是由发布引起的。
•07.测试管理
O代码静态检查
・代码静态检查,即静态代码分析,是指不运行被测代码,仅通过分析或检查源程序的语法、结构、过程、接口等检查程序的正确性，并找出代码中隐藏的错误和缺陷（比如参数不匹配、有歧义的嵌套语句、错误的递归、非法计算、可能出现的空指针引用等等）。
・在整个软件开发生命周期中，有70%左右的代码逻辑设计和编码缺陷属于重复性错误,完全可以通过静态代码分析发现和修复
・SonarQube是一款目前比较流行的工具,国内很多互联网公司都选择用它来搭建静态检查的平台
o破坏性测试
■
•第一，破坏性测试的手段和过程，并不是无的放矢，它们是被严格设计和执行的。
不要把破坏性测试和探索性测试混为一谈。
•第二,破坏性狈赋,会产生切实的破坏作用，你需要权衡破坏的量和度。
•破坏性测试与普通测试流程,唯一不同的是,绝大部分昔通测试可以在测试失败后,继续进行其他的测试；
而破坏性测试,则有可能无法恢复到待测状态,只能停止后续的测试。
•绝大部分破坏性测试都会在单元测试、功能测试阶段执行。
而执行测试的环境也往往是局部的测试子环境。
■优点
•破坏性测试还能很好地证明整个分布式系统的健扌士性
・走义
•破坏性测试就是通过有效的测试手段,使软件应用程序岀现奔溃或失败的情况,然后测试在这样的情况下,软件运行会产生什么结果，而这些结果又是否符合预期
・混沌工程
•混沌工程是在分布式系统上建立的实验，其目的是建立对系统承受混乱冲击能力的信心。
鉴于分布式系统固有的混舌属性,也就是说即使所有的部件都可以正常工作，但把它们结合后，你还是很难预知会发生什么。
•通过一些受控实验,我们能够观察这些弱点在系统中的行为。
这种实验方法”就被叫作混沌工程。
•案例
O混沌工程的一个典型实践是,Netflix公司的ChaosMonkey系统。
这个系统已经证明了混沌工程的价值和重要性，值得我们借鉴
oChaosMonkey会在工作日期间,随机地杀死一些服务以制造混乱,从而检验系统的稳走性。
而工程师们不得不停下手头工作去解决这些问题,并且保证它们不会再现。
久而久之，系统的健扌士性就可以不断地被提高。
・科学实验的四个必须步骤
•科学实验都必须遵循的4个步骤：
将正常系统的一些正常行为的可测呈数据走义为"
稳走态"
；
建立一个对照组,并假设对照组和实验组都保持"
引入真实世界的变呈，如服务器崩溃、断网、磁盘损坏等等;
尝试寻找对照组和实验组之间的差异,找出系统弱点。
"
稳定态"
越难被破坏，则说明系统越稳固；
而发现的每一个弱点，则都是一个改迸目标。
oMock与回放
・Mock
•如果某个又嫌在测试过程中依赖于另一个复杂又嫌,而这个复杂又嫌又很难被从测试过程中剥离出来,那么就可以利用Mock去模拟并代替这个复杂对象。
•嗨
o基于对象和类的Mock
・适合模拟DAO层的数据操作和复杂逻辑,所以它们往往只能用于单元测试阶段
・推荐Mockito、EasyMock
O基于微服务的Mock
・到了集成测试阶段，你需要模扌以一个外部依赖服务时，就需要基于微服务的Mock
・推荐WeirMock、MockServer
・回放
•定义
O要做到和实际用户操作一致,最好的方法就是记录实际用户在生产环境的操作，然后在测试坏境中回放
•实现
O即先通过虚拟交换机，复制和记录生产用户的实际请求,在测试时"
回放"
这些真实操作，以达到更逼真地模扌以用户行为的目的
•08.持续交付平台化
O好处及原因
・随着软彳判支术的发展「壬何企业最终都将面临多技术栈的现实
・随着持续交付业勢的发展,团队会越来越庞大,分工也会越来越明细
・随着持续交付技术本身的发展，还会不断引入新的工具,或新的流程方法
O初衷
・互联网厂商平台化的玩法，往往是指自己搭台子,让其他人唱戏。
・高可用、可扩展
O平台四大核心模块
・四个模块是持续交付平台中最核心，最容易做到内聚和解耦的模块。
每个核心模块的周围,又围绕着各种子模块,t匕如：
代码管理模块，往往会和代码审核、静态扫描和分支管理等模块相联系；
集成编译模块，也会与依赖管理、单元测试、加密打包等模块相生相随的；
环境管理模块，离不开配置管理、路由管理等模块;
发布部署模块,还需要监控模块和流控模块的支持。
O抽象公共服务
・需要抽象的公共功能，主要包括：
账户与权限,包括单点登录，以及鉴权、授权体系等等;
用户行为日志,即任］可行动都要能够被追溯；
消息通知，即提供统一的通知能力；
安全与故障处理，即系统级的防护能力和故瞳降级。
O细节
・标准先行
O云计算带来的变革
・云计算的弹性能力，使得计算资源的提取成为持续交付过程的一个自然步骤。
・云计算的Immutable,可以保证计算资源的生命周期与持续交付过程一致。
・云计算本身不区分环境,这样可以获取与生产环境几乎一样配置的资源。
o缠说话
■如何衡呈系统健康度
•有的时候即使宕机了，特别是在夜间，因为没有用户使用，其实际影响几乎为0
•宕机时间这个单一指标，不能全面地评价系统的稳走性
•采用如下的实施方案：
首先，我们通过监控、保障、人为记录等手
间和故障时长。
然后，计算过去三个月内这个时间段产生的持续交付平均业务星。
所谓业务星,就是这个时间段内，处理的代码提交、
codereview;
进行的编译、代码扫描、打包;
测试部署；
环境处理;
测试执行和生产发布的数星。
最后，计算这个时间段内的业务臺与月平均呈相比的损失率。
这个损失率，就代表了系统的不稳走性率，反之就是稳创生率了。
・注重长尾
•看数据不仅要抓大势，也要关注细节,特别是异常细节。
•大的故障和影响,往往都是岀于一些非常愚蠢的失误。
-常用衡星指标
•稳走性
•性能
O与性能相关的扌颤,我匕傲关注的有：
push和fetch代码的速度;
环境创建和销毁的速度;
产生仿真数据的速度;
平均编译速度及排队时长;
静态检查的速度;
自动化测试的耗时；
发布和回滚的速度。
•成熟度
o与代码管理子系统相关的指标包括：
commit的数星，codereview的拒绝率,并行开发的分支数星。
O与环境管理子系统相关的指标包括：
计算资源的使用率,环境的平均大小。
O与集成编译子系统相关的指标包括:
每日编译数呈,编译检查的数据。
O与测试管理子系统相关的指标包括:
单元测试的覆盖率,自动化测试的覆盖率。
O与发布管理子系统相关的指标包括：
周发布数星，回滚t匕率。
•09.持续交付移动4PP
O移动端交付和后端服务交付的不同点
・对于移动App的持续交付来说,我们特别需要维护版本的相关信息,并对每个版本进行管理。
・移动App和后端服务的持续交付体系,在构建管理上的不同点，主要体现在以下三个方面：
你需要准备Android和iOS两套构建环境，而且iOS的构建坏境还需要一套独立的管理方案。
因为，iOS的构建环境，你不能直接使用Linux菌以机处理，而是要采用Apple公司的专用设备。
在整个构建过程中,你还要考虑证书的管理，不同的版本或使用场景需要使用不同的证书。
如果证书比较多的话,还会涉及到管理的逻辑问题,很多组织都会选择自行开发证书管理服勢。
为了解决组件依赖的问题，你需要持别准备独立的中央组件仓库，并用缓存等机制加快依赖组件下载的速度。
其实，这一点会和后端服务I：
匕较相像。
・发布管理
•首先，移动App无法做到强制更新，决走权在终端用户。
•其次,移动App在正式发布到市场前,会进行时间比较长的内测或公测。
•最后，移动App的分发渠道比较多样。
o移动App的持续交付体系的搭建完全可以借鉴服务端的持续交付的经验。
然后，再针对移动App固有的特点,进行改迸和优化。
o移动APP交付流水线pipeline
・发布快车模式
•发布快车,就像一列由多节车厢组成的火车，每一节车厢代表一个发布版本,整个火车以一节节车厢或者说一个个版本的节奏,走期向前发车。
而工程师们,则会把自己开发完成的功能集成到一节节的车厢上,这样集成在一节车厢的功能代码,就形成了一个新的版本。
•三个关键点
o第一个关键点是,并不是说所有开发的功能,都一走要集成到最近的那节车廂、最近的那个版本中。
o第二个关键点是,我们必须要保证固走间隔的发车时间,每周、每两周都可以，但必须保证每个车厢到点即发。
O第三个关键点是,这个过程的最终产物是可以发布到市场的版本,而不是发布到用户侧的版本。
•代码分支策略
•构建通道
O我们会在功能分支合并入Master分支前，增加一次构建
（MergeCIService）,这次构建的作用是保证功能分支的集成是成功的,否则不允许合并；
同时,对于一个代码仓库来说,增加的这次构建过程要保证是串行的，即如果这个仓库正有一个合并构建在逬行，则后续的合并构建需要等待。
o发布流程
・iOS系统的发布步骤为：
构建，导出ipa包，记录符号表，备份,上传至iTC;
Android系统的发布步骤为：
构建打包,更新渠道标识，签名，保存mapping文件，备份，上传至发布点。
o提升效率
・提升效率最好的方法就是2个字：
解耦。
落到技术实现上来说,就是通过组件化形成合理的开发框架
・实践经验:
利用组件化的思想提升开发效率，但同时也会带来组彳牛依赖及发布的问题；
利用扁平化依赖管理的方法解决组件依赖和发布的问题，同时采用二进制交付的方式,进一步提高构建效率；
合理利用静态代码扫描、UI自动化、自动Monkey等测试工具和方法,逬一步提升测试效率;
确保分发的精准性和稳走性,是提升发布效率的有效手段。
•01•持续交付体系概述
O要点
・配置管理
・环境管理
・构建集成
・测试管理
O趋势
・"
持续交付"
必须以平台化的思想去看待，单点突破是无力的；
的实施,也要顺应技术的变迁，善于利用技术红利;
与系统架构、运维体系息息相关,已经不分彼此。
O误区
・过度强调自动化
■过度强调溺呈化
・过度强调特殊化
O难点
・事难做
・人难找
・效果难以度量
O目的
・提高研发效率
•02•基本概念
O持续集成
・这个从编码到构建再到测试的反复持续过程,就叫作"
持续集成"
O持续交付
・这个在"
之后，获取外部对软件的反馈再通过"
逬行优化的过程就叫作"
它是"
的自然延续。
是一个承上启下的过程,它使"
有了实际业务价值,形成了闭坏,而又为将来达到"
持续部署"
的高级目标做好了铺垫。
・从"
（自动化发布）开始推进"
这才是一条优选的路径。
O持续部署
-”持续部署”就是将可交付产品,快速且安全地交付用户使用的一套方法和系统，它是"
的最后"
一公里"
O价值
・显性价值
•在"
最终用户"
和"
研发团队"
之间建立紧密的反馈环：
通过持续交付新的软件版本,以验证新想法和软件改动的正确性，并衡星这些改动对软件价值的影响。
这里说的"
软件价值”，说白了就是收入、日活、GMV等KPI指标了。
-隐性价值
•对于管理者
o技术选型
o标准落地
o协作效率
o黑天鹅防范
•对于团队主管
O知识传递
O专注于业务
O持续工作
•对于产品经理
O产品的第一个用户
o进度和质星
O随时发布
•对于程序员
O加强对软件工程的认识
O工作效率和质量
O挑战和乐趣
O如何衡呈绩效
・将所有的"
不可持续点"
进行记录和分解,通过OKR的考评方式,将消灭这些点作为目标，拆解出来的可行动点，作为关键结果,以这样的方式来完成绩效考评。
o影响持续交付的因素
・人（组织和文化）
•第一个层次：
紧密配合，这是组织发展，部门合作的基础
•第二个层次：
集思广益,这就需要组织内各个不同部门,或不同职能的角色,跳出自身的"
舒适区"
•第三个层次：
自我驱动,是理想中的完美组织形式
•软件企业与交付有关的研发部门包括四个：
产品、开发、测试和运维。
而这四个部门天然地形成了一个生产流水线
•如何解决组织问题
O成立项目管理办公室（ProjectManageOffice,简称PMO）这样的监督型组织,帮助持续交付落地；
O独立建立工程效能部门，全面负责包括持续交付在内的硏发效
率提升工作;
使用
壬形式，如Scrumr打破职能部门间的〃隔离墙"
产品的形式组织团队，各团队自行推进持续交付0
•文化先行是前提
■事（流程）
•耗时长的流程
•完全人工的流程•信息报备类的流程
O持续交付过程中同样会产生各种信息流，这些信息有些需要广播，有些需要走点传递。
实施持续交付后，这些信息报备类的流程一走会通过异步i
升级会员 