手机显示的网站该怎样设计,wordpress远程附件,网站主题分析,扬州做阿里巴巴的公司网站简介#xff1a;全线专栏《研发效能提升36计_持续交付篇》上线啦#xff01;本专栏将通过10-20篇文章#xff0c;系统分享云原生时代#xff0c;企业如何落地持续交付。本文是该专栏的第2篇。 什么是真正的持续交付#xff1f;
编者按#xff1a;全线专栏《研发效能提升…简介全线专栏《研发效能提升36计_持续交付篇》上线啦本专栏将通过10-20篇文章系统分享云原生时代企业如何落地持续交付。本文是该专栏的第2篇。 什么是真正的持续交付
编者按全线专栏《研发效能提升36计_持续交付篇》上线啦本专栏将通过10-20篇文章系统分享云原生时代企业如何落地持续交付。本文是该专栏的第2篇。 什么是真正的持续交付
首先我们先看一下什么是持续交付。我们认为持续交付至少应该包含这4点
● 持续顾名思义是均匀的、分散的。具体来说是要
粒度小 持续发布的粒度一定要很小大了便很难做到“持续”。
频率高发布频率要非常高。
● 快速 持续交付中整个的交付过程是很快的交付频率也是很高的。要做到快速需要。
工序短在测试、发布、开发等各个阶段中都要做到“短”。这样才能做到快速地反馈、快速地响应。
等待少 工序和工序之间、工序和其他流程之间的等待应做到“少”。
反馈快 提交代码后应在尽短时间内反馈此次提交的问题应尽快修复问题再尽快得到又一次的修复反馈。
● 高质量持续交付是要能够保证质量的一定要做到高质量。高质量需要保证
质量可见性 判断做得好不好首先我们要看到它所以可见性是非常重要的。
缺陷少 软件应是按照预期设计去运行的而不是有很多潜在的缺陷在里面。
故障少 每次软件故障带来的不仅仅是客户的损失也是软件团队的损失。很多客户机会、业务资产会因为故障太多而白白损失掉。
● 低风险在现在的互联网环境下风险无处不在所以我们要做到安全、合规且可信。
软件可观测 要知道软件的风险最重要的一点就是可观测知道软件当前是什么样子的。
发布可控 我们后续会专门讲到。
问题可回溯 如果出现了发布问题或软件故障我们能够回溯整个问题的来源。从哪开始、从哪个地方引入的都需要能回溯起来。
系统可回滚 如果有问题真的解决不了或没法快速解决我们需要能够快速把它回滚掉以避免造成更大的风险。
以上是持续交付的4个关键点只有满足了持续、快速、高质量、低风险这4点才是实现了持续交付。 这4点是缺一不可的。粒度小、频率高是快速的前提。相应地只有质量高了风险才能够低一些。
问题是如何做到呢
基于云和云原生技术的持续交付 我们认为云原生时代要实现持续交付需要做到这3点不可变基础设施、持续交付流水线、安全可信发布。
1、不可变基础设施 有一本书叫做《集装箱改变世界》。这本书讲述了集装箱的发明让原本零碎松散的货物运输体系变成以集装箱为单位并由此带来了整个货运成本的95%的降低。
如果我们看软件交付以往我们的开发语言构建方式是各种各样的程序的打包、运行、管理方式也都不一样这些不同使得我们的软件交付面临着很大的风险。
在容器出现之前大家在运维工具、部署工具上做了很多尝试但是都不太成功整体也不如容器流行。其原因便是容器做的就像集装箱做的事情——标准化。
基于容器我们又做了K8S做了容器的分发和整个部署运维体系运行的环境也做掉了。在此基础上诞生了各种各样的云原生的数据库、云原生的中间件。这样云原生的整体标准就出来了。就像集装箱带来的改变一样研发体系实现了标准化由此我们便可以以相同的方式去对待不同技术栈写出的程序。
整体来看不可变基础设施的应用为我们带来了以下几点“红利”
1消除了不一致带来的不确定性 以前一个程序换了一个环境可能就跑不动了其中的问题便是底层出现了不一致带来的bug。
2减少不一致的风险 风险很难预估。像一个Java程序里面你大部分跑的是对的但是在某些情况下它会出现异常小版本的差异会产生更多异常的风险。这种情况下你会发现风险是非常难排查的而且风险带的后果很严重。
3减少维护成本 因为很多底层的东西被标准化了就不用我们去做了。比如K8S就做了很多这样的事情。
4部署简化了 都是同样一套东西就像集装箱一样运输就是了。
5环境维护成本降低了 普遍使用标准化后便不需要有太多的负担只要遵照这个标准就行。
6工具的开发和学习成本的降低了。
不可变基础设施带给我们非常大的技术红利我们生态越来越完整。只是这时我们原来的习惯、思维或者工作方式都要发生变化。
2、持续交付流水线 持续交付流水线一定程度上是把我们的整个软件交付的过程完整地串接在一起。
上图展示的是一个非常典型的流水线从代码提交到合并、构建、生成一个制品、接口测试、功能验证、类生产环境部署验证到最终验收、上线。
这个流水线是一个完整的过程。没有间断、没有跳过是一层层往后走的。
有了这个流水线之后如果代码质量很好、自动化率很高整体就会自动地在很短的时间内告知我们上线成功。这是一个非常美妙的体验流畅而省力。
要想达到上面流畅的体验我们对流水线是有要求的具体来说有如下几点
1可描述性
流水线是研发模式的具象化表达 流水线应该是一个可描述的东西。研发模式其实是通过流水线或其他一些手段描述出来的。
发布流程的一致性 有了流水线之后每次的发布流程都是一样的。
最佳实践可快速复制 在一个公司里不同团队的研发实践差别往往非常大因为很多东西是在口口相传或者是文档里的不同的人对其中内容有不同的掌握、解读方式。但是流水线可以实现快速的复制。把流程用文章写出来不如让它落实在流水线中效果好。
2可观测性
开发、发布过程可见 在流水线中不仅仅是当前的发布、开发过程是可以看到的历史发布过程、开发过程也是可以看到的。每一次的发布经过了哪些阶段、每个阶段是什么结果都是可以看到的。如此便可以知道整个流程是什么样子整个流程的质量是什么样子中间哪个节点有可能出现问题。
发布过程有保障 整个流水线中我们看到有很多的验证节点、接口测试、预发验收。所有这些节点的成本都不小但是它们却能保证最后发布上线的结果是成功的、稳定的。如此有了流水线的运用整个发布过程就有了保障。
3自动化
自动化顾名思义就是尽量减少人工在过程中的干预。若每一次阶段间的衔接是靠人工完成的它中间的等待时长以及它的协同成本就会比较高会带来各种各样的风险所以我们应该做到整个发布过程是完全自动化的。从代码提交到最后上线全过程是完全由流水线牵动的。即使中间有些步骤需要人去做验收或者测试但是这也只是一个工序。这个工序完了之后执行人点个确定说我验收成功了之后就会自动地往下发。因此整个过程是一个自动化的过程。
3、安全可信发布 在软件交付中一个代码、配置甚至是一个依赖的变化都会引发制品的改变。制品的改变会经过流水线的一系列节点。这些节点中间有很多需要去验证、关注和管控的点例如代码审查、测试验证、评审、发布管控也会有很多的规则、检测项例如代码质量合规、安全检测。
这些规则加上这些检测项会最终形成一个反馈表明这次发布是不是可信的。如果反馈有问题那就不应该发布如果反馈没有问题那便可以继续往下走。
作为安全可信发布来讲首先它要能够降低发布的风险防止缺陷带来的业务损失。更重要的是降低发布的心智负担不会不敢发布。
同时通过安全可信发布我们可以获得质量的反馈让质量是看得见的。让我们能做到及时反馈、及时修复整个开发效率就会变高。
享受持续交付的红利 持续交付可以带来很多的好处例如
1消除对个人的依赖 所有的信息都是共享的可见、可控、可度量、可加速
2降低团队之间的损耗 流程一致所有版本一致出现故障时更好处理。
3降低测试成本、提升质量 自动化的测试是可以回归的可以不断地运行的也可以重复的成本远低于手工测试。在微服务架构下如果出现问题也可以更清晰、方便地定位。
4降低发布风险 版本可以回溯一致性也比较好因而发布风险也会很好地被控制。另外有了可信发布的支持整体的发布成功率也会更有保障。
接下来我们将从不可变基础设施、持续交付流水线、安全可信发布3个层面逐一深入 通过系列文章为大家一一讲解。
原文链接
本文为阿里云原创内容未经允许不得转载。
