持续交付

最近某位大神在推特上发了一个帖子，后果引来了国内泛滥卖课机构、培训机构的狂欢，开始贩卖焦虑，其实「平台工程」也不是什么特地高深莫测的货色。闲得无聊，把这位大神的几个帖子薅了下来，你看过之后就会感觉也没啥，都是相熟的货色。 Sid Palas & 平台工程这位大神的名字叫 Sid Palas，一位专门做 DevOps 和 Cloud infra 相干工作的小伙伴。为了让大家理解他，他的 github 我附在最初了。上面就是这个十分有意思的帖子。原帖能够到推特下来围观。共有六局部，第一局部我贴了原图，前面的五局部我把文字复制了过去。 DevOps is dead , long live Platform Engineering! 1) Developers don't like dealing with infra 2) Companies need control of their infra as they grow. Platform Engineering (and Internal Developer Platforms) enable these two facts to coexist. DevOps 已死，平台工程永存。1) 开发人员不喜爱与基础设施打交道 2) 公司在倒退时须要管制他们的基础设施。平台工程（以及外部开发者平台）能够同时满足这两个诉求。 Fact 1: Most developers don't like dealing with infrastructure. They want to write code and run it somewhere but don't care much where that is. Functions as a Service (e.g. Lambda) or Platforms as a Service (e.g. Vercel) provide this experience. 事实 1：大多数开发人员不喜爱解决基础设施。他们想编写代码并在某个中央运行它，但不太关怀运行在哪里。函数即服务（例如 Lambda）或平台即服务（例如 Vercel）提供了这种体验。 ...

在从继续交付到业务翻新（上）：互联网时代研发效力的外围中，何勉老师讲了疾速继续的交付价值是互联网时代研发效力的外围，并分享了如何度量这一能力，并通过无效的实际来建设这一能力。 然而，光有继续交付价值的能力还不够，咱们必须保障交付的货色是有用的，能带来真正的价值。而什么才是真正的价值，是一个翻新和摸索的过程。 这是何勉老师将要要分享的第二局部——无效的业务翻新。 无效的业务翻新离不开继续交付能力的反对。继续交付能力让咱们能够更快的获取反馈，它是互联网时代翻新的根底。互联网时代的翻新到底有什么不同呢？咱们看上面这幅图。 第一幅是局部共享单车App的图标，其中相当局部在过来一年曾经退出了竞争；第二幅是局部直播App的图标，业界风行所谓“百团千播”一说，“百团”说的是当年的团购大战，“千播”说的直播竞争的盛况空前，现在直播风潮还未过来，小视频的战火又曾经燃起。 挪动互联网时代，守业和产品开发的老本大幅升高，触达用户的渠道也更加间接，用户的抉择急剧减少，选择权迅速从生产者转移到了消费者一侧了。交付的货色，用户不会抉择或者基本不在乎，成为翻新过程中最大的节约。 除此之外，咱们还不得不面对减速变动的世界，业界称其为乌卡（VUCA）时代。乌卡最早用来形容热战后的国内政治环境，它由Volatility（易变性），Uncertainty（不确定性），Complexity（复杂性），Ambiguity（模糊性）四个单词的首字母形成。明天乌卡被更多用来形容技术和商业环境，而这也是产品交付和翻新所必须面对的环境。 环境减速变动和选择权向用户侧转移，这两个趋势对产品的翻新和交付模式，提出了全新的挑战。咱们须要更无效的产品翻新模式。 以继续交付为根底，咱们有机会也必须引入零碎翻新办法。这就是咱们前面要讲的从继续交付到产品翻新。 无效的翻新从明确指标开始。指标从哪里来？它源自使命和愿景，源自使命和愿景在空间和工夫上的合成。所谓空间合成是指合成和剖析达成指标的各个因素，以及各个因素之间的关系。而工夫合成指如何按步骤的去构建这些因素，实现这个最终的指标。 先看一个空间合成。为此，要先介绍一个概念叫飞轮效应。飞轮的概念最早是在《从优良到卓越》这本书提出来的，作者柯林斯通过钻研那些基业长青的企业发现，在它们背地往往都存在一个飞轮——也就是业务的正向增强循环。如果去仔细分析，这个飞轮也存在于所有疾速倒退的互联网业务中。 以亚马逊为例，贝佐斯在97年上市招股书外面就明确提出并形容了亚马逊的飞轮。咱们要为用户提供足够多的抉择，抉择多用户体验就好，体验好用户流量就会多，流量多，就会吸引更多卖家退出，从而提供更多用户抉择，实现更好的体验，造成正向反馈，不断加强实现增长。这个飞轮还有另一个分支，业务规模的增长带来更好的老本构造，这样价格就会更低，这也会促成客户体验变好，这个循环也是飞轮的一部分。 飞轮效应看上去很美，然而它的艰难之处在于如何启动和维持它。为了使静止的飞轮转动起来，一开始你必须使很大的力量，一圈一圈重复地推，每转一圈都很费劲，然而每一圈的致力都不会徒劳，飞轮会转动得越来越快。当达到一个很高的速度后飞轮所具备的动量和动能就会很大，使其短时间内停下来所需的外力便会很大，便可能克服较大的阻力维持原有静止。 飞轮的另一个难点在于，它环环相扣，一个环节脱节它就转不起来，比方在亚马逊的例子中，如果用户的外围体验并不是抉择多，他们不会因为抉择多就来到网站，那咱们就必须从新开掘用户的诉求或问题。正因为如此，咱们才必须晓得飞轮背地的逻辑是什么，有哪些假如。验证这些假如，构建正当的商业闭环，飞轮能力真正运行起来。 咱们能够从很多胜利的业务中看到这样的飞轮。淘宝、盒马、抖音、微信背地咱们都能看到他们的飞轮。飞轮是实现规模化的产品的必备选项，否则以明天竞争环境之残暴，他人的产品有飞轮，而你没能胜利构建的话，那你就很难竞争了。 让咱们虚构一个场景，假如咱们要做一个短视频利用，相似抖音，看看咱们最后构想的飞轮是什么样的呢？ 以下只是实践上的推演，事实中的状况肯定要简单很多。 更好的观看体验带来更多用户应用，更多的用户应用就带来更多的内容发明，更多的内容发明就带来更多的优质内容，更多的优质内容又带来更好的体验，造成增强回路。这是飞轮的外围，问题是从哪里开始旋转飞轮呢？这成了先有鸡还是先有蛋的千古难题。 咱们先欠缺一下飞轮的形成因素，再来剖析。更好的体验，还可能产生更多的分享，而分享带来新的用户。增长带来更多支出可能，支出多的话就会带来更多KOL（达人），KOL带来更多优质内容，并且一些素人也会成长为KOL。飞轮更欠缺了，但鸡和蛋的问题仍然没有解决。比方在你可能带来可观支出之前，KOL凭什么来？KOL不来又如何实现增长和带来支出？ 为了飞轮转起来，咱们必须找到初始的转动把手。比方，对于更多优质内容，咱们能够先去梳理现有的内容供应，保障初期的供应。或者开掘OGC周边内容，保障继续的精品内容的供应，这些行为在飞轮的周边，没有先有鸡还是先有蛋的问题，是咱们能够着力的中央。因而咱们称之为把手。 图上，咱们剖析了启动和继续驱动飞轮的把手。比方，初始的KOL怎么来？你可能须要内容补贴，或者是站外拉取等等。比方，如何构建更好的初始观看体验因素？比方，如何让用户奉献内容发明？等等。 除此以外，还有十分重要的一点，就是在增长中如何建设适合的调性。这也是让飞轮能够绝对长期运行必须思考的。快手和抖音的调性就不同，也决定了其后的扩张门路和难度的不同。并不是孰优孰劣，重要的是，这对你前面的增长策略影响很大，需在业务倒退过程中给与关注。 基于业务指标，咱们构建了增长飞轮，并合成了驱动飞轮运行的把手。这是对愿景和使命在空间上的合成，它给出了从哪里着力去构建产品和业务模式的初始方向。 有了空间的合成，从实践上，咱们有了转动增长飞轮的着力点。但咱们还必须面对一个问题——具体从哪个中央开始。这就是咱们接下来要讲的从工夫上合成。先关注什么，后关注什么？这是一个门路问题，谬误的门路是产品翻新过程中常常会犯的谬误。 对于产品翻新的门路问题，咱们要介绍一下关隘模型。它认为做守业或者做一个新产品、新的业务须要通过各个阶段，每个阶段是上一阶段的前置条件，因而称之为关隘模型——过了上一关能力进入下一关。 关隘模型的第一步是共情——发现一个未被满足的需要，有足够强的理由引发用户的趣味，这是产品存在的理由；接下来是粘性——解决方案要可能让用户违心继续应用；而后是病毒——用户违心通知或拉来他们的敌人一起应用；再而后是支出——你得有反对继续经营和增长的支出起源；最初才是规模化。 关隘模型的外围是“关隘”——过了上一关能力进入下一关。比方没有共情就不可能有粘性；没有粘性你也无奈让产生口碑和病毒，即便通过激励的伎俩又不长久，而且病毒带来的用户也会散失。 为什么要介绍关隘模型呢，因为它看上去很简略、正当，但事实中，咱们还是会一再犯错。特地是在产生粘性之前，就去规模化扩张。这是最常见的谬误，这和人类急功近利本色以及KPI的影响都有关系。 关隘模型，为愿景和使命在工夫上的合成提供了概念上的领导。 回到增长飞轮，咱们如何判断从哪里开始，找到着力点呢？根本的判断是，从用户体验开始，它与用户的共情和粘性间接相干。 还是以亚马逊的飞轮为例，粘性来自于什么？当然是用户的体验，所以从用户体验登程，是启动飞轮运行的要害。在亚马逊的案例中，用户的体验的外围是价格和抉择。但做到这一点并不容易，如果亚马逊一开始就做全品类，那须要花很长时间也不会构建起根本的用户体验，亚马逊也不可能保持到明天。 了解了这一点，咱们就能了解亚马逊为什么要从图书做起，因为在那个时刻，图书是最有可能和疾速建设起抉择和价格这两大体验的。亚马逊最后的LOGO上也写着，寰球最大的书店就是这个情理。图书是亚马逊其后20年品类扩张的起始。 咱们说以体验为外围，但对体验是什么肯定要有本人的了解。体验绝不仅仅是网站或 App 的交互好这么简略，它体现为特定场景下，用户外围诉求被满足的水平。 比方盒马，它最后定位解决的是25岁以上都市白领买菜的问题，那它的外围体验就是：1）所想所得，你一想到马上就可能送到，半小时送达；2）一站式购齐，比如说买韭菜炒香干，有韭菜，没有香干，就不是好的体验；3）足够陈腐和不便，这是它的外围体验。 比如说百度做MP3的时候，俞军面试产品经理，有一道题目是如何能力做好百度 MP3 产品。其他人洋洋洒洒写了几页纸，而李明远就写了两句话，六个字——搜失去，能下载。这就是抓住了外围体验。 小视频的外围体验又是什么呢？我看到的是：继续供应的优质内容，并且能精准的散发。做到这两点并不容易。这是咱们一开始应该聚焦的中央。可能还应该更聚焦，如针对一小部分初始外围人群的优质内容和精准散发。 不同的人对外围体验会有不同的了解, ，你可能也有本人的了解，比方感觉用户的参加和自我展示才是最外围的诉求，这都能够，要害是你必须对外围体验有一个明确且聚焦的定位，还必须可能差异化和聚焦，这只是举个例子，必定不容易，特地是一个追赶型的产品。 这就是咱们所说的工夫上的合成。你必须在一开始聚焦外围的点，这个外围的点往往是体验，不同产品体验是不同的，围绕体验要做的事件也并不少，团队应该尽量聚焦，比方抓住外围体验和外围人群。盒马就是一个很好的例子，只管幻想很大，但一开始他们牢牢抓住了都市白领一日三餐这个外围场景，做深做透，满足用户的外围诉求，打造本人的外围能力。 这是工夫的合成的例子，它的外围是必须聚焦，正确的工夫做正确的事，一步一个脚印，能力更松软的进入上面的步骤。还是以盒马为例，解决好三口之家买菜的问题。为盒马建设了两个根底：1）对用户而言是心智——盒马是一个身边的牢靠服务；2）对外部而言是能力——供应链能力，治理能力等等。这时咱们进入上面的阶段，才更牢靠。不论是口碑的建设——如：本地社区的经营；还是服务类型的扩张——如：24小时应急服务，3公里的生存服务圈等；还是规模和渠道的扩张。 以上，咱们分享了对指标和愿景在空间和工夫的合成。它们是产品翻新过程的出发点。对于空间的合成咱们讲了，如何构建增长飞轮，以及找到飞轮的把手。它是对业务增长的根本逻辑的假如，而业务胜利是建设在这些假如的根底上的，因而咱们必须在产品交付和翻新过程中一直的验证调整，打造无效运作的业务闭环；对于工夫的合成，咱们介绍了关隘模型，以及从用户体验开始，找到着力点，开始最早的业务闭环的打造和摸索。 对指标和愿景在工夫和空间上的合成，咱们构建了业务大图，它领导咱们在什么时刻关注什么指标。接下来，咱们还要对指标进行量化，量化的指标和度量让咱们更可能晓得咱们是否在向着正确的方向后退。 怎么去量化呢？这就要回到具体的产品，去看产品的指标。为此，咱们须要构建产品的大图，从产品的大图上，发现和定义正确的指标。 满足用户的诉求是产品的外围，从用户应用门路登程来构建产品大图是无效办法。还是看假想的小视频例子，图中每一个框是用户的一个行为节点，其中深蓝色的框是内容生产的节点，浅蓝色的是内容生产的节点，绿色的是咱们最冀望产生的用户行为——在这里是内容的公布和观看以及关系的积淀。 看一下最外围的行为门路。最上方是用户从哪里来。用户进入后，可能会间接生产内容——如拍摄上传，更可能从生产内容开始。内容生产过程中会产生互动，如：评论、关注等，也有可能被疏导向话题参加或者是内容创作。对于内容创作也存在一系列门路，包含进入、选素材、拍摄、编辑、公布等，其中任何一步用户都可能退出。不论是内容生产还是公布，咱们都心愿用户可能踊跃的分享，分享带来新的用户流量。最右边是站外的内容供应。 用户门路图的外围是用户，也就是产品满足用户并疏导用户行为的过程。产品的胜利，很大水平上取决于用户行为的转化，咱们的服务是否满足了用户，并且让用户产生了冀望的行为。比方，各个环节的转化率、沉闷率和留存率等。 咱们称用户门路图为产品大图，基于产品大图咱们设计和扫视更正当的产品门路，定义外围的产品指标。图中，红色和灰色的文字是其中一些产品指标，其中红色是以后时刻重点关注的指标，它们大部分与用户的外围体验和粘性相干，如用户人均VV（video view播放视频）数、次日留存，视频的播放完成率等。 基于业务大图，咱们确定了特定时刻的次要指标。基于产品大图，咱们能够进一步确定相干的指标。定量指标答复的是 Why 的问题，接下来咱们要摸索用什么抓手 (How) 实现目标，以及通过什么样的产品性能或经营流动 (what)。从Why 到 How 再到 What 这是定义产品性能的门路。 ...

本期的分享嘉宾是阿里巴巴阿拉丁团队的资深技术专家何勉老师，何老师也是国内最早的精益产品开发实践者之一，专一于产品开发和产品设计及翻新两方面的摸索和实际，帮忙组织晋升效力，使其顺畅、高质量交付有用价值。 本期课程将围绕着麻利产品开发维度，从麻利开发的指标、定义和进步继续交付能力、麻利在继续交付的根底上的翻新实际和全栈麻利四个维度，带咱们摸索麻利研发的冰山一角。 大家好，明天咱们分享的主题是：《从继续交付到业务翻新》，我将从麻利产品开发讲起。 从实质上讲麻利开发的一个重要指标是建设继续价值交付的能力。这种能力最终必须服务于业务的翻新，促成业务的胜利。绝对应的，明天分享的内容，蕴含两个方面，第一：什么是继续交付以及如何建设继续交付能力；第二：以继续交付能力为根底，落实业务翻新的实际，造成无效的翻新闭环。这是明天分享题目——“从继续交付到业务翻新”的由来。具体蕴含以下4个局部： 第一：麻利开发的指标； 第二：定义和进步继续交付能力； 第三：在继续交付的根底上落实翻新实际； 最初是一个总结，咱们会提出全栈麻利 Full Stack Agile 的概念，它是技术和治理的综合，也是交付和翻新的综合。 第一局部：麻利开发业务指标咱们常常会说麻利模式，那什么开发模式是不麻利呢？对，咱们通常说“瀑布”是不麻利的。 瀑布开发模式把开发分成一系列阶段，如需要、设计、开发、测试，就像上图它画进去的，看起来很像瀑布，所以叫瀑布开发。问题是需要的交付难道不都是要经验这些阶段吗？ 瀑布开发的实质问题并不是阶段，而是批量。需要批量地在一起进行设计，而后是批量地开发，批量地测试、交付等等。批量有什么问题? 首先，批量让价值交付提早，所有需要在最初的阶段能力交付，价值交付比拟晚。     价值交付比拟晚又怎么样？看这幅图。右边是Intel的创始人摩尔，摩尔定律的提出者。摩尔定律通知咱们，18个月之后，用同样的钱能买到多一倍的货色，比方计算能力、存储量、晶元数等等。而左边这位是Google执行董事长施密特，他提出了反摩尔定律，表述为：“如果18个月之后咱们只能卖出跟明天一样的货色，咱们就只能失去一半的支出”。 反摩尔定律是摩尔定律的一个简略推论，它通知咱们，越迟交付的价值也是越低的价值。对硬件公司这很要害，甚至决定它们的的宿命——技术提高必须跟得上摩尔定律，否则利润就会被摩尔定律吞噬，让产品或公司走向灭亡。 软件或互联网服务又怎么呢? IBM在上世纪90年代，意识到不能做一家硬件公司，转而主攻服务和软件行业，它确实过了一段好日子。然而，很快互联网时代到来了，软件和服务行业的翻新一下子减速了。这时，绝对硬件公司，反摩尔定律在软件和互联网服务公司的作用是有过之而无不及的，工夫的迟早可能不仅仅决定价值的多少，有时错过整工夫窗，可能会满载而归。 反摩尔定律通知咱们，越迟交付的价值也是越低的价值。所以对于软件开发来说，瀑布模式提早了价值交付，失去的价值也更少。绝对瀑布，咱们提出了迭代交付，咱们把开发分成迭代，每个迭代交付一部分价值，更早交付的价值往往意味着更多的价值。就这一点来说，迭代绝对瀑布的实质是，更小批量的疾速交付，从而更早获取更多价值，和获取市场竞争的先机。 所以麻利开发有第一个指标就是更快的交付价值，这里的快指的不是绝对速度，而是更早的交付。 第二点，咱们再看一个坐标图，这个坐标是我的项目的工夫历程，最左是我的项目开始，最右是我的项目完结。纵坐标是团队领有的这个我的项目和产品的常识，比如说用户要什么，采取什么样的产品计划，应该做什么样的性能，以怎么的模式来合作，抉择什么样的技术计划等等。 咱们想问一下团队（包含产品也包含开发、业务）什么时候对于产品和我的项目的常识最充沛、最多？大家的答案都很统一，我的项目完结的时候。这不言而喻，咱们在我的项目过程中积攒了常识，特地是当向用户交付产品后，用户反馈：“我要的不是这个啊，我说的明明是…”，这时候你霎时狂涨常识，并感叹道“你怎么不早说呢？”。这两头可能有沟通问题，但更多可能的是，用户这时才分明或可能形容他们要的是啥，更有甚者，咱们可能一开始连用户是谁也未必能精确的定义。产品和业务开发原本就是一个摸索的过程，开始时肯定是最无知的时刻。 再问一个问题。我的项目中的大部分决策，是什么工夫做出的呢？大家的答案也很明确——我的项目开始的时刻。这里埋藏了一个重大的悖论，咱们在最无知的时刻，做出了最重要而且是绝大部分的决策，并把它作为随后执行的根据。面对不确定的技术、市场环境，传统开发模式已无奈适应要求，悖论越发突出。 对于这一悖论，麻利的对策还是迭代。开始时，咱们会做出一些初始的决策，比如说总体目标是什么，大略的策略和打法是什么，从哪里开始，怎么测验等等。但这些只是初始决策，定义了大抵的方向。在整个开发过程，咱们迭代交付需要，获取市场的反馈和最新的信息，并基于这些反馈和信息，积攒和修改对产品的认知，增量地决策和调整。 产品开发过程中，技术环境、市场环境、竞品策略、团队认知都会发生变化。面对变动的环境，咱们必须抵赖本人的无知，在开发过程被动无效地学习，一直地吸取反馈，灵便地调整。这也是麻利的第二个业务指标，无效学习和灵便响应变动。 综合下面提到的麻利开发的两个业务指标，咱们就能够给麻利开发下一个定义了。麻利指的是创立一个组织更快（早）的交付价值，和更无效学习和灵活应变的能力。 从能力的角度，麻利的外围是继续交付价值的能力，以及以继续交付为根底的疾速反馈学习能力。为了具备这样的能力，产品的开发和交付形式须要做出根本变化。这幅图从概念上体现了，传统批量式的开发方式到麻利的继续交付形式的转变。 传统开发方式下，需要成批量的流经各个阶段和组织部门，如产品、UED、开发、测试、经营等直至交付，各个职能各自优化本人的工作，造成效率竖井。因为批量的起因，需要期待整个批量实现，能力集中进入下一阶段。从单个需要的角度看，需要大部分工夫都处于期待状态。 上图的右半局部表白了这一过程，单个需要的理论解决的工夫很短（图中折线中下面绿色的短线），它们大部分工夫都处于期待状态（图中折线上面红色的长线），最终体现出的理论交付周期很长。 通过麻利施行，咱们心愿整个组织协调一致，更严密合作，缩短交付周期。图中左半局部是现实的麻利开发模式，它体现了麻利开发的根本指标——继续价值交付和疾速反馈、学习，这其中继续价值交付是根底。 问题是如何能力建设和改良继续价值交付能力呢？ 第二局部：定义和晋升继续交付能力管理学之父德鲁克说：“如果你不能度量它，你就无奈改良它”。对于继续交付能力，这同样实用。 无效的度量体系应该围绕外围问题开展。在这里，这个基本问题就是团队的继续价值交付能力如何？咱们将用五组指标来答复这一问题，它们别离是： 第一：公布能力，具体蕴含两个细分指标，别离是：1）公布频率，也就是团队均匀多长时间公布一次需要。它束缚了团队对外响应的最大可能；2）公布前置工夫，也就是从代码提交，到性能上线所须要破费的工夫。如果工夫开销很大，团队就不太可能去加大发版的频率。 第二：需要响应周期，它蕴含两个细分的指标，别离是：1）交付周期时间，也就是从用户提出需要并被确认，到需要上线所要经验的时长。它反映团队（蕴含业务、开发、经营等职能）对客户问题或业务机会的整体响应速度；2）开发周期工夫：从开发团队了解并确认需要，到需要能够上线所经验的时长。它反映研发的响应能力。前面咱们还会更具体解读两个周期。 第三：交付的吞吐率，也就是单位工夫内交付的需要的个数。 第四：内建品质的能力，也就是整个交付过程的品质。它蕴含两个细分的指标，别离是：1)开发过程中缺点的创立和修复工夫的散布。咱们心愿缺点可能及时且继续的发现，并且在发现后尽快修复；2）缺点库存，咱们心愿能在整个开发过程中管制缺点库存量，让产品始终处于靠近可公布状态，奠定继续交付的根底。对于内建品质的能力的具体度量办法，咱们前面还会具体介绍。 第五：对外交付品质。它蕴含两个细分的指标，别离是：1)单位工夫（线上）问题数目；2）（线上）问题均匀解决时长。 好的度量体系应该答复一个基本问题，并为此讲述残缺的故事。为答复团队交付能力如何这一问题， 下面5组指标，别离从响应能力、效率和品质三个方面提供一个残缺的故事。其中，继续公布能力和需要响应周期这两组指标反映的是响应能力，也就是价值的流动效率；交付吞吐率这一指标反映的是团队效率，也就是资源的产出效率；内建品质的能力和对外交付品质这两组指标是质量指标。这些指标综合起来，让咱们能够全面理解以后交付等能力，与指标的差距，以及改良的机会。 以上是度量体系的总体设计，咱们把周期时间作为掂量团队响应能力的外围指标。这幅图更直观地展现了两个周期时间的计算形式，以看板的工作流为根底，客户周期时间的终点是从需要被抉择开始，到需要公布完结；开发周期工夫则从待开发开始，到待发布完结。 基于下面的度量指标体系，咱们抉择和设计了相干的图表，来出现这些度量。上面咱们介绍其中的一些例子。 第一是累积流图。累积流图再现了团队合作交付价值的过程，它的横坐标为日期，纵坐标为各阶段累积实现的需要数目。从左至右的各条线，反映各个阶段累积解决实现的需要数量。例如：图中最下面这条线是曾经就绪的需要的个数，最上面这条线是曾经上线的需要的个数，两头这条线别离是曾经开发的、开发完结的、曾经测试的、测试完结的等等。 累积流图综合反映了均匀交付周期、在制品数量、达到和交付速率三类指标。 第一：均匀交付工夫。交付工夫指需要交付之前从开始到完结所经验的工夫。图中，到3月26日这一天累积打算了40个需要，而到5月15日这一天累积交付了40个需要。假如需要合乎先入先出（先打算的先交付）的法则，那么第40个需要的交付周期时间就是 5月15日 - 3月26日 = 50（天）。之所以要在交付工夫之前加上“均匀”，是因为并非所有的需要都是先进先出。从累积流图上还能够进一步看出交付工夫在各个阶段的散布。 第二：在制品的数量。在制品（Work in Process）指正在解决的需要的数目，也就是所有开始但还没有实现的需要的数目。如：上图中4月15日这一天，累积开始的需要有61个，累积上线的需要是8个。在制品数量 = 61- 8 = 53（个），它们曾经开始，但还没有交付。从累积流图上还能够进一步看出在制品在各个阶段的散布，如开发中的，待测试的，测试中的等。 ...

编者按：全线专栏《研发效力晋升36计_继续交付篇》上线啦！本专栏将通过10-20篇文章，零碎分享云原生时代，企业如何落地继续交付。本文是该专栏的第2篇。 策动&编辑｜雅纯 什么是真正的继续交付？首先，咱们先看一下什么是继续交付。咱们认为，继续交付至多应该蕴含这4点： ● 继续：顾名思义，是平均的、扩散的。具体来说是要： 粒度小： 继续公布的粒度肯定要很小，大了便很难做到“继续”。 频率高：公布频率要十分高。 ● 疾速： 继续交付中整个的交付过程是很快的，交付频率也是很高的。要做到疾速须要。 工序短：在测试、公布、开发等各个阶段中都要做到“短”。这样能力做到疾速地反馈、疾速地响应。 期待少： 工序和工序之间、工序和其余流程之间的期待应做到“少”。 反馈快： 提交代码后，应在尽短时间内反馈此次提交的问题，应尽快修复问题再尽快失去又一次的修复反馈。 ● 高质量：继续交付是要可能保证质量的，肯定要做到高质量。高质量须要保障： 品质可见性： 判断做得好不好，首先咱们要看到它，所以可见性是十分重要的。 缺点少： 软件应是依照预期设计去运行的，而不是有很多潜在的缺点在外面。 故障少： 每次软件故障带来的不仅仅是客户的损失，也是软件团队的损失。很多客户机会、业务资产会因为故障太多而白白损失掉。 ● 低危险：在当初的互联网环境下，危险无处不在，所以咱们要做到平安、合规且可信。 软件可观测： 要晓得软件的危险，最重要的一点就是可观测，晓得软件以后是什么样子的。 公布可控： 咱们后续会专门讲到。 问题可回溯： 如果呈现了公布问题或软件故障，咱们可能回溯整个问题的起源。从哪开始、从哪个中央引入的，都须要能回溯起来。 零碎可回滚： 如果有问题真的解决不了或没法疾速解决，咱们须要可能疾速把它回滚掉，以防止造成更大的危险。 以上是继续交付的4个关键点，只有满足了继续、疾速、高质量、低危险这4点才是实现了继续交付。 这4点是缺一不可的。粒度小、频率高，是疾速的前提。相应地，只有品质高了，危险才可能低一些。 问题是：如何做到呢？ 基于云和云原生技术的继续交付 咱们认为，云原生时代，要实现继续交付须要做到这3点：不可变基础设施、继续交付流水线、平安可信公布。 1、不可变基础设施 有一本书叫做《集装箱扭转世界》。这本书讲述了集装箱的创造让本来系统涣散的货物运输体系变成以集装箱为单位，并由此带来了整个货运老本的95%的升高。 如果咱们看软件交付，以往咱们的开发语言构建形式是各种各样的，程序的打包、运行、治理形式也都不一样，这些不同使得咱们的软件交付面临着很大的危险。 在容器呈现之前，大家在运维工具、部署工具上做了很多尝试，然而都不太胜利，整体也不如容器风行。其起因便是容器做的就像集装箱做的事件——标准化。 基于容器咱们又做了K8S，做了容器的散发和整个部署运维体系，运行的环境也做掉了。在此基础上，诞生了各种各样的云原生的数据库、云原生的中间件。这样云原生的整体规范就进去了。就像集装箱带来的扭转一样，研发体系实现了标准化，由此咱们便能够以雷同的形式去看待不同技术栈写出的程序。 整体来看，不可变基础设施的利用为咱们带来了以下几点“红利”： （1）打消了不统一带来的不确定性： 以前一个程序换了一个环境可能就跑不动了，其中的问题便是底层呈现了不统一带来的bug。 （2）缩小不统一的危险： 危险很难预估。像一个Java程序外面，你大部分跑的是对的，然而在某些状况下，它会出现异常，小版本的差别会产生更多异样的危险。这种状况下你会发现危险是十分难排查的，而且危险带的结果很重大。 （3）缩小保护老本： 因为很多底层的货色被标准化了，就不必咱们去做了。比方K8S就做了很多这样的事件。 （4）部署简化了： 都是同样一套货色，就像集装箱一样，运输就是了。 （5）环境保护老本升高了： 广泛应用标准化后便不须要有太多的累赘，只有遵循这个规范就行。 （6）工具的开发和学习老本的升高了。 不可变基础设施带给咱们十分大的技术红利，咱们生态越来越残缺。只是这时，咱们原来的习惯、思维或者工作形式都要发生变化。 2、继续交付流水线 继续交付流水线肯定水平上是把咱们的整个软件交付的过程残缺地串接在一起。 上图展现的是一个十分典型的流水线：从代码提交到合并、构建、生成一个制品、接口测试、性能验证、类生产环境部署验证到最终验收、上线。 这个流水线是一个残缺的过程。没有间断、没有跳过，是一层层往后走的。 有了这个流水线之后，如果代码品质很好、自动化率很高，整体就会主动地在很短的工夫内告知咱们上线胜利。这是一个十分美好的体验，晦涩而省力。 要想达到下面晦涩的体验，咱们对流水线是有要求的，具体来说有如下几点： （1）可描述性 流水线是研发模式的具象化表白： 流水线应该是一个可形容的货色。研发模式其实是通过流水线或其余一些伎俩形容进去的。 公布流程的一致性： 有了流水线之后，每次的公布流程都是一样的。 最佳实际可疾速复制： 在一个公司里，不同团队的研发实际差异往往十分大，因为很多货色是在口口相传或者是文档里的，不同的人对其中内容有不同的把握、解读形式。然而流水线能够实现疾速的复制。把流程用文章写进去不如让它落实在流水线中成果好。 ...

编者按：从今天起，咱们将开启一个新的专栏：《研发效力晋升36计_继续交付篇》。专栏将通过10-20篇文章，零碎分享云原生时代，企业如何落地继续交付，本文是该专栏的开篇。 策动&编辑｜雅纯Dora在2018年DevOps年度报告中对软件交付效力提出了一组度量指标，以掂量一个企业的软件交付程度。 部署频率。指利用将变更部署到生产环境的频率。如每天都有部署，一天能部署十次，还是一天部署一次，或者一个月才部署一次。变更前置时长。指从代码提交到部署上线并在生产环境运行起来的时长。服务复原工夫。是服务中断之后到下一次服务可能复原以持续服务的时长。变更失败率。是指对生产环境的变更失败的比率，总共变更了多少次，其中有多少次是失败的。能够看到，“精英”团队的部署频率基本上是按需——只有想公布，就能够随时公布下来。咱们将“低效能”和“精英”之间一比拟，再对照一下本人的团队，就能够看到本人是属于哪一个象限里，是属于精英、低效能、高效能，还是中等效力。 当然，对于变更失败率一项，有些同学会说：“我每次公布都胜利了，我是百分百的。”其实不然，一次实现公布过程，且两头没有任何的干涉，也没有预先的修复、回滚是很难的。 在跟很多业务团队、包含里面公司的同学交换时，咱们发现，无论是CTO、CIO、还是一线的研发人员，大家都面临一个问题：“我想扭转”、“我想做得好”、“我想成为精英”，然而理论做到却很难。为什么？ 因为： 1.治理老本越来越高。 人越来越多，治理老本越来越大，合作复杂度也越来越高，散会的工夫比干活的工夫还多。 2.技术债权也越来越高。 理论生产中，业务往往不会给你很多工夫去在一开始就做得很好。于是便有了“我不论怎么样先把业务它跑起来。”然而可能过了一年或者两年之后，你会发现它跑不动了。这种情景在互联网守业外头叫糙快猛。技术债权越来越高之后，要再去做一些事件，就要连本带息要一起还了。 3.新技术引入十分艰难。 有一些比拟好的技术因为人员的老本的问题，找不到十分优良的人。另外，有一些技术的门槛较高，须要的技能也纷繁复杂。 不仅如此，软件交付状态的变动也对软件交付效力提出了挑战。 1.继续的产品交付对软件研发模式要求更高以前的软件交付是有里程碑的，然而当初不一样了，咱们心愿每天都有新的货色进去，而不是去实现几个里程碑、或者是三个月、一两年后再出一个货色。咱们心愿软件的交付是继续地、增量产生的。 以电信设施为例，电信设施的交付，开发环境和生产环境网络是不通的，换而言之，去做一次公布和施行的老本特地高。 这时候，继续的交付就对软件的研发模式提出了更高的要求。不可能再有很长时间的plan，而后等到半年后或者两年后做一个集成来交付施行。它要求你每个迭代都有货色进去。 2.继续降级的服务对可用性提出了更高的要求当软件能够做到继续公布、降级了，软件的可用性也会相应地被提出更高的要求，不能动不动就断了。对客户来讲，他看到的就是你的一个服务，他对你提供的服务是有感的，因而你的服务须要十分高的可用性。 3.继续的交付须要能高效保障产品质量品质对继续交付是十分重要的。当产品公布上线，如果有品质问题就很容易导致故障，甚至导致须要公司露面来去做公关。近几年也有很多这样的例子。 俗话说，有挑战就肯定有时机。具体来看，云原生时代，咱们面临着2大时机，能够帮忙咱们晋升软件交付效力。 时机1：技术倒退推动利用架构及部署架构的演进 （1）利用架构的演进 咱们会发现，技术的倒退实际上在推动咱们的利用架构和部署架构的演进。从资源的角度来说，以前咱们利用云托管，而后倒退为云优化，再到当初的云原生。咱们会发现资源产生了一些变动，而利用架构的也同样产生了变动——从单体利用逐步倒退为了Severless。也就是说从原来挨得越来越近，到缓缓地分得越来越开、拆得越来越小。 （2）部署架构的演进 从部署架构的角度来说，咱们也能够看到一些变动，从原来的物理机到当初的BaaS/FaaS。 这样的演进也让咱们的整个交付变得更灵便、更解耦，能够做到想发就发，甚至让工程师更多的关注在业务逻辑上。 时机2：云基础设施和云原生技术的衰亡 （1）云基础设施的档次越来越高 当初云基础设施的抽象层次越来越高了。其实在13年的时候，咱们过后对于云基础设施的了解都是“infrastructure”。但随着容器的衰亡，咱们逐步看到了容器平台，而后咱们又有了PaaS，咱们不须要再去关怀音讯队列、存储、监控等。而今，咱们领有了Serverless，简直是能够不必写后端，整个的利用后端全副在云上。要做的就是写业务逻辑，而且简直是前端的业务逻辑。后端服务我只须要依照使用量付费就能够了。 （2）K8S成为事实标准，云原生成为趋势 从K8S到当初的CNCF，咱们会发现目前K8S曾经是一个事实上的规范。大家不会再去探讨要不要去做云原生，当初的问题是怎么做。 （3）微服务化背景下，服务治理的诉求越来越大 大家都在谈微服务，但微服务会带来很多之前没有的问题。其中一个比拟典型的问题就是服务治理。服务太多，怎么进行服务治理、服务发现怎么做、负载平衡、容量调度等等，各种问题都来了。所以大家对服务治理的诉求就变得越来越大。 与此同时，服务的数量越多，复杂性就越高。比方，若一个服务的可用性是99.9%，10个9服务累加便是99.9%的10次方。另外，它自身的复杂性也会越来越高。好比说两个人之间交换很简略的，但三个人交换的时候，我的链路就多了一些。再加上分布式服务间的网络通信，各种各样的异常情况都会呈现。这些都是十分事实的问题，也会给咱们带来很大的老本。 总结来看，现在咱们的软件交付与以前有了十分大的不同。 云原生时代，咱们须要继续交付的模式，以实现更快、更高质量的软件交付。 然而，大多数时候概念非常美妙，落地却有各种各样的苦楚。 云原生时代，咱们该如何落地继续交付？接下来，咱们将通过系列文章，与大家一起梳理云原生时代继续交付的系列实际，敬请期待。 也欢送在评论区留言，与云效专家互动，说出你想听到的内容～ 欢送大家应用云效，云原生时代新DevOps平台，通过云原生新技术和研发新模式，大幅晋升研发效率。现云效公共云根底版不限人数0元应用。 点击下方链接立刻体验云效DevOps全家桶！ https://www.aliyun.com/produc... 对于咱们 理解更多对于云效DevOps的最新动静，可微信搜寻关注【云效】公众号； 福利：公众号后盾回复【指南】，可取得《阿里巴巴DevOps实际指南》&《10倍研发效力晋升案例集》； 看完感觉对您有所帮忙别忘记点赞、珍藏和关注呦；

前 言Github 引入了Pulll Request拉取申请（简称PR）实际和相干的反对性能，使运行开源我的项目的人更容易接受来自他们信赖的提交者群体之外的奉献。 Committer是被信赖的主体，能够定期更改代码库。然而须要评估来自随机内部人员的更改，以确保其无效，不会使我的项目朝着不须要的方向倒退，并且合乎格调和质量标准。内部人员将他们提出的变更打包为拉取申请，Committer能够轻松地将其作为一个单元进行审查和治理，而后再将其合并到代码库中。 （图 1：拉取申请流程） 只管拉取申请旨在更容易地承受来自团队内部不受信赖的人的奉献，但现状是很多团队对内部人员应用拉取申请。这种做法曾经变得如此广泛，以至于许多人将其视为默认的“最佳”实际。有些人认为没有其余办法能够确保代码失去评审，因为他们从未见过其余任何货色。 然而，拉取申请会就义性能，包含交付工夫和品质。当治理来自未知人员的变更危险时，这是一个值得做出的就义。内部人员可能不理解你我的项目的愿景和方向。他们在测试、代码品质和格调方面可能没有雷同的习惯和标准。然而，你本人团队成员外部应该共享这些标准。 针对本人团队成员的代码变更采纳拉取申请，就像让你的家人通过机场安全检查站进入你家一样，这是针对不同问题的低廉解决方案。 应用继续集成而不是拉取申请软件交付过程应该针对流程和品质进行优化。将变更前置放弃在较短的工夫，并在变更引入问题时提供疾速反馈。这是反对继续集成(CI)的想法。CI 是在每个人的代码上一直合并和测试他们的做法。 （图 2：继续集成过程） “当他们工作时”是必不可少的。作为团队成员，你不会等到实现某个性能或故事后才将代码集成到骨干中。相同，你常常 - 至多每天一次 - 将你的代码置于衰弱状态，通过测试并将其与其他人的当前工作一起集成到骨干中。（另请参阅 Martin Fowler 对于分支模式的文章和 Paul Hammant 的基于骨干的开发。） 每次推送变更时，CI 构建作业都会自动测试我的项目的骨干。这意味着在投入太多工夫之前，你会立刻发现你正在做的事件是否与另一个人正在做的事件发生冲突。当你认为曾经实现了一个故事或性能，却发现必须回去解决并重做这几天的致力，会很蹩脚。 （图 3：每次推送时都在集成代码上运行测试） 拉取申请的麻烦拉取申请会提早集成。当实现工作，认为已筹备好与团队其余成员的工作进行集成时，你创立一个拉取申请并期待有人对其进行审核。只有在其他人审查通过变更后，才会将其与骨干集成。 如果团队成员疾速审查和集成拉取申请，这仅比 CI 慢一点。兴许他们会在你每次推送的30 分钟内回复并审核，将你的代码变更与骨干集成，并针对它运行自动化测试。因而，你可能会在 30-40 分钟左右之后发现与其他人的工作发生冲突。 （图 4：拉取申请与 CI 的反馈提早） 在实践中，没有多少团队能在 30 分钟内牢靠地解决拉取申请。在期待某人审查你的变更时，你能够切换到另一个工作或开始解决新的批改。当发现存在问题时，你须要切换回原始更改，从而中断了以后的工作流程。 另一方面，无效的 CI 构建应该在推送集成代码后的几分钟内实现测试 - 在咱们的场景中最多 10 分钟。你简直会立刻发现该抵触，因而能够对其进行考察和修复。 在从测试齐全集成的代码中取得反馈之前，你无需打断其他人的工作来要求他们对其进行审查。正如我将很快解释的那样，你可能依然须要有人审核变更。然而你能够利用更快的周期时间来提交、集成和测试本人的代码，以便在要求他们审查之前进行多项更改。 即便团队中的每个人都很快地扭转了拉取申请，典型的做法是等到实现性能或故事的工作，而后再将拉取申请与骨干集成。大多数团队均匀须要超过一天的工夫来开发一个故事。因而，典型的拉取申请流程不满足继续集成的最低要求，即至多每天集成每个人的工作。 每天数次以编码、拉取、测试、推动和从集成测试中获取反馈的节奏工作会令人兴奋，而拉取申请在节奏中引入人为提早，不可能产生这种兴奋感。 审查代码更改更好的办法当 CI 与拉取申请的话题呈现时，不可避免地会有人站进去为拉取申请辩护，以获取其余团队成员对更改的反馈。 必须有第二双眼睛（如果不是更多）查看代码更改。人类会发现测试没有发现的问题，尤其是与可维护性和设计相干的问题。让人们审查彼此的代码还有助于团队在编码格调、编程习惯和品质要求等标准上趋于统一。在某些状况下，例如受监管的环境，须要由第二人审查每个更改。 然而，最近拉取申请的风行仿佛导致一些人认为没有其余办法能够用来审查代码变更。以下是你能够应用的一些实际，而不会中断继续集成反馈周期。请记住，齐全能够依据须要进行多个实际的组合。 （图 5：配对以实现即时、继续的代码审查） 结对编程：没有任何模式的代码审查比结对编程更无效。反馈是即时的，因而应用它进行改良的可能性要高得多。如果有人在你编写代码时通知你有更好的办法，那么你能够立刻进行、学习并以更好的形式编写代码。如果有人在一天后通知你，你能够将其记录下来以备未来参考。然而要让你进行以后的工作并回去重做你曾经实现的工作，这会成为一个重大的问题。定期审查：如果合规性没有明确要求进行审查，则可能不须要为每个代码更改设置一个门禁。你可能有定期的、预约的审查，例如每周，来查看自上次审查以来的代码更改。这作为小组练习尤其无效，因为它创立了对话，帮忙人们学习和塑造团队的编码标准。流水线审批：如果你的团队应用继续交付流水线将变更交付到生产，能够包含一个阶段，要求有人受权变更进行。这在概念上相似于拉取申请，因为它是交付过程中的一个门禁，但当你将门禁放在代码集成和自动化测试之后。这样做意味着人们只花工夫审查曾经在技术上被证实是正确的代码。 （图 6：在集成和测试之后审查更改） 论断拉取申请与继续集成的不同之处在于，在编写代码变更之后但在将其与主线集成之前，须要人工审查代码更改。这会提早从已齐全集成代码的自动化测试中获取到反馈。 ...

一、背景如果您应用的是函数计算（FC），要将您的代码部署到函数计算，并以事件驱动的形式触发函数执行。那么本文档能够帮忙您实现研发流程的协同自动化。云效继续集成流水线 Flow，是企业级继续集成和继续交付工具，通过构建自动化、集成自动化、验证自动化、部署自动化，实现从开发到上线CICD过程。通过继续向团队提供及时反馈，让交付过程高效顺畅。 二、云效解决方案通过云效继续交付流水线和函数计算（FC）很好的联合在一起，为利用的继续交付提供了很好的根底保障，如下图： 开发者提交代码变更到代码库，云效在监听着代码库的变动，一旦代码发生变化，将主动触发流水线一次构建工作的运行，流水线会主动拉取您更新的代码分支，并公布到您的 FC 函数服务上。这所有，都是通过自动化的伎俩进行实现，您无需再手动下载代码文件并打包上传至您的 FC 函数服务。 三、云效操作实际目前云效反对您通过三种形式公布至函数计算： 1.间接通过代码仓库的源码公布。 2.通过 OSS 上传公布，适宜须要在 OSS 上对您每次公布的源码文件进行存储管理的场景。要应用这类公布形式，您须要在公布前在云效里将您的源码文件打包后上传至 OSS。 3.通过镜像公布，适宜您的函数服务运行环境为自定义环境 custom-container，须要通过镜像来公布您的函数服务的场景。要应用这类公布形式，您须要在公布前在云效里进行镜像构建并推送至阿里云容器镜像服务（ACR）。 本文次要介绍第一种形式，间接拉取源码公布至函数计算服务。1、创立流水线 进入云效，点击页面左上角的dock，抉择流水线进入Flow阐明 立刻体验：云效流水线Flow 点击右上角【新建流水线】，进入流水线创立向导页面。 抉择空模板，并点击创立 2、配置代码库 创立流水线之后会自动弹出增加代码源的窗口，这里抉择你的代码源，并进行增加。本文增加的是 Flow 的 FC 示例代码源（https://code.aliyun.com/flow-example/fc-node-sample.git）。 3、配置 FC 公布工作 删除多余的“空工作”，点击增加新的工作组”函数计算利用公布”。 点击“新建服务受权”，实现服务受权后，抉择您 FC 的服务名和函数名，填写您的代码路径名，实现 FC 公布工作配置。 4、增加人工卡点 为了保障通过审批的制品能力进入部署环境，须要增加一个人工卡点，这里假如这个环境是测试环境，须要有测试管理员来审批能力进入。 首选须要在企业中创立一个角色”测试管理员“，并将企业用户”张三”的角色设置为该角色。 而后回到流水线持续进行配置，在 FC 公布后面增加一个工作，搜寻”人工卡点“，并依照角色进行配置： 5、运行流水线 配置结束，点击”保留并运行”触发流水线： 流水线停在了卡点上，一般人员无权限通过，切换到张三的账号之后，能够通过或者回绝。 点击”验证通过“，流水线会进入 FC 公布的工作。 6、告诉 为了更好的进行合作，Flow提供了告诉能力在流水线不同的生命周期节点上进行告诉。一般来讲开发团队会关怀部署的胜利和失败，那么能够将该事件推送到团队的钉钉群中，配置形式如下，点击”增加插件”，抉择钉钉机器人告诉，填入webhook地址，运行机会抉择”失败“，”胜利” 再次运行之后，就会收到相应的告诉： 本文次要介绍间接拉取源码公布至函数计算服务。帮忙您实现研发流程的协同自动化。云效继续集成流水线 Flow，是企业级继续集成和继续交付工具，通过构建自动化、集成自动化、验证自动化、部署自动化，实现从开发到上线CICD过程。通过继续向团队提供及时反馈，让交付过程高效顺畅。

1 背景小型企业个别是指研发人数少于30人的企业，这些企业有的处于生存期，有的处于发展期，要求产品迭代速度要赶上市场更新速度。对于研发流程，个别没有专职的管理人员，心愿引进成熟的计划把游击队革新成正规军，用小而精的技术团队驱动大业务、大市场，进而实现企业和团队的大倒退。 你有问题，我有计划。云效助力中小企业倒退，适宜你的解决方案才是最好的计划。任何软件研发过程都必须解决两个问题：代码怎么管、产品怎么发？不心愿引入简单的流程、不心愿减少额定的人员耗费，又能够解决理论问题并取得效力晋升。借助云效，只须要“十分钟，两步走”您就能够领有成熟的继续交付能力： 第一步，用云效代码平台进行代码托管和评审； 第二步，用云效流水线进行继续集成和交付。 2 以后小型企业继续交付中遇到的挑战如果没有引入成熟的工具和办法，研发过程个别面临这些挑战： •团队没有对立的研发治理流程，工具无约束，恪守流程标准根本靠盲目； •日常公布流程中人工干预过多，不足自动化部署能力； 满足团队日常开发的需要，可能顺畅地部置到生产环境，须要： •对立的代码托管和评审； •统一的构建和运行环境； •标准的自动化公布流程。 3 基于云效解决方案3.1 云效继续交付能力 云效，企业级一站式DevOps解决方案，源于阿里巴巴先进的治理理念和工程实际，致力于成为数字企业的研发效力引擎!云效提供从“需要->开发->测试->公布->运维->经营”端到端的协同服务和研发工具，反对公共云、专有云和混合云多种部署状态，通过人工智能、自动化技术的利用助力开发者晋升研发效力，继续疾速交付有效值。 3.2 咱们的劣势 3.2.1 代码治理 •自动化代码检测，提供平安扫描疾速裸露代码平安问题，同时提供代码规约查看保障代码品质。 •阿里巴巴自研，适宜企业级代码库，提供企业间数据隔离及企业-代码库-成员三级权限管控能力。 •平安稳固的代码库，欠缺的日志审计、IP白名单等实现访问控制，让你的代码平安无忧。 •多样化代码评审，欠缺的配置能力反对丰盛的代码评审场景，自动化代码扫描进步评审效率。 阐明 立刻体验：云效代码治理3.2.2 流水线 •钉钉音讯告诉，流水线运行后果，即时精确地反馈到钉钉群。升高沟通老本，晋升团队工程协同。 •疾速生成流水线，实用多种场景，通过模版来疾速创立流水线，提供可视化编排和后果展示，所见即所得; •自动化品质保障伎俩，反对代码扫描、平安扫描，人工测试卡点等多种品质红线，确保业务交付品质。 •反对多语言，Java、Node.js、Python、PHP、Golang等语言脚手架生成代码框架，能够对接支流代码仓库； •软件公布反对，保障业务稳固交付，通过灰度公布、分批公布的策略，保障业务交付的稳固。 阐明 立刻体验：云效流水线Flow3.3 解决方案架构图 联合代码治理平台和继续交付流水线，为小微企业实现随时集成，每日交付提供了很好的根底保障，真正实现继续疾速交付无效价值。 •过程中任何问题通过钉钉，自动化地及时反馈到指定负责人，做到精确反馈、即时响应，疾速复原。 •开发者依据工作安顿，创立个性分支，通过线下编译和自测通过提交代码； •代码提交主动触发代码扫描，通过后发动合并申请，依据代码库设置发送给指定的代码评审员进行评审； •实现代码评审后合并集成分支，主动触发集成分支流水线，实现构建、部署和测试环境验证工作，验证通过合并到公布分支； •依据公布工夫人工触发公布分支流水线，实现构建、预发部署验证、公布审核等流程，审批通过部署生产环境； 3.4 两步开启继续交付 第一步，先把代码托管起来疾速创立代码仓库通过代码库右上角，点击【增加代码库】，能够抉择新建代码库和导入代码库，代码库克隆反对HTTPS和SSH两种协定； 开启代码扫描在提交和合并申请中，能够主动触发代码扫描工作。目前提供了两种扫描能力：敏感信息扫描及Java规约扫描。管理员能够在【设置】-【集成与服务】中开启设置代码扫描的机会，或者开启和敞开扫描； 引入代码评审通过【分支设置】实现代码评审场景定制，例如设置集成分支为爱护分支，须要通过新建合并申请-通过合并申请-合并分支流程实现； 第二步，用流水线实现主动交付一键创立流水线点击流水线列表右上角的【新建流水线】按钮，开始创立流水线，抉择研发语言和流水线模版； 编辑流水线场景通过流水线编辑性能，联合企业场景疾速配置以下2条流水线： •集成环境流水线 【步骤阐明】 *触发形式抉择：代码提交触发； *集成分支开始构建编译； *编译通过部署测试环境； *测试同学测试验证； *验证通过代码合并公布分支； •公布环境流水线 【步骤阐明】 *公布分支开始构建编译； *编译通过部署预发环境； *预发环境验收测试； *验证通过开始公布单审核； ...

什么是云效流水线 Flow，如何在云效上创立流水线，「流水线」，又名「Flow」，是一款企业级、自动化的研发交付流水线， 提供灵便易用的继续集成、继续验证、 继续公布性能，帮忙企业高质量、高效率的交付业务。云效流水线是继续交付的载体，通过构建自动化、集成自动化、验证自动化、部署自动化，实现从开发到上线过程的继续交付。通过继续向团队提供及时反馈，让交付过程高效顺畅。更多「云效」产品，查看：云效疾速入门 为什么抉择云效「Flow」 更多的源 源，不只是代码，云效「Flow」反对灵便的触发源定制，帮忙企业更随心的执行继续集成和继续部署。云效「Flow」 反对将业界通用的代码仓库作为流水线的触发源，包含： Codeup阿里云Code自建Git码云GiteeGitlab私有云Github私有云Github企业云BitbucketCoding自建 Jenkins 服务Flow 流水线源，还有更多。 在不久的将来，云效「Flow」还会继续反对更多的触发源，包含但不限于： 制品仓库存储 OSS弱小的研发分支治理能力 阿里巴巴在 DevOps 的最佳实际也体现在分支治理能力上，云效Flow 反对将罕用的研发模式融入流水线，将企业 云效DevOps 的整个体系流程化。 骨干开发Gitflow分支开发保障高质量的交付 云效「Flow」 提供代码扫描、 平安扫描和各种自动化测试能力，反对人工测试卡点、自动化验证卡点等多种品质红线，确保业务品质。 如何应用品质检测能力，可查阅“品质检测”一章 更优良的软件公布反对 云效「Flow」和阿里云产品深度集成，反对不同国家，不同云厂商以及专有云环境公布。通过灰度公布、分批公布的策略，最大限度的防止了不稳固公布对用户的影响， 保障业务交付的稳固。 云效「Flow」反对的部署能力包含： • 主机脚本部署 • 灰度公布 • 分批公布 • Docker 部署 • 滚动公布 • Docker 部署 • 蓝绿公布 • 分批公布 • 阿里云 EDAS 部署• 阿里云SAE部署• Kubernetes • Kubectl公布 • Kubernetes镜像降级 • Kubernetes分批公布 • Kubernetes蓝绿公布 • Helm Release公布 • 阿里云函数计算FC公布• 资源编排服务ROS公布如何应用部署能力，可查阅“部署”一章 丰盛而灵便的模版 ...

云效继续交付流水线，收费还好用！流水线继续交付「流水线」，又名「Flow」，是「云效」产品矩阵中一款企业级、自动化的研发交付流水线，提供灵便易用的继续集成、继续验证、继续公布性能，帮忙企业高质量、高效率的交付业务。流水线是继续交付的载体，通过构建自动化、集成自动化、验证自动化、部署自动化，实现从开发到上线过程的继续交付。通过继续向团队提供及时反馈，让交付过程高效顺畅. 点击立刻体验 新建流水线 点击产品右上角【新建流水线】，抉择对应的开发语言，能够查看以后语言下的默认流水线模版，能够依据模版疾速创立流水线场景； 抉择代码源 抉择完模版后，能够抉择你应用的代码源，输出代码地址实现创立。 编辑流水线 通过流水线编排，你能够定义继续交付的自动化流程，将构建，部署，测试，管控等组件化能力进行编排和串通，实现从开发到上线过程的自动化流程。流水线提供了以下编排能力：• 阶段：在流水线中须要按程序执行的一组工作的汇合，一个阶段能够是手动运行也能够是主动运行的。阶段之间串行执行；• 工作：在阶段中具体须要实现的动作，工作之间能够串行执行也能够并行执行，目前工作蕴含：代码扫描，单元测试，构建，部署，合并代码，人工审核等性能。• 步骤：步骤作为最底层的外围能力，所有的流水线都是通过步骤的编排组合而成的。 运行流水线 流水线反对不同类型的触发策略，你能够依据本人的应用场景，抉择适宜的形式来触发流水线运行，以后反对的触发策略包以下几种：• 手工触发：用户可在流水线上点击“运行”来进行手动执行。• 代码提交触发：配置 WebHook 后，在相应的代码地址和分支上提交代码后就能够触发流水线的运行。• 定时触发：能够周期性的主动触发流水线的执行。在编辑流水线时，能够点击定时运行，而后配置定时配置。 查看最近运行 拜访流水线列表，会在列表中展现以后流水线的【最近一次运行后果】的状态和运行缩略图。 开启质量检查 在流水线步骤中增加代码扫描和测试步骤，云效自带多种语言的代码扫描和测试组件，也能够通过自定义命令的形式执行本人的测试。 品质红线是流水线提供的品质卡点能力，用于标准化质量标准，当阶段中存在品质项尚未达标的状况下，阻止公布流程进入到下一阶段（环节）。 点击流水线页面各阶段测试报告，能够查看具体的测试后果进行剖析； 钉钉音讯告诉 流水线中配置钉钉群告诉插件，能够将流水线运行过程中的信息反馈相应同学，便于疾速定位和排查问题，钉钉群流水线运行后果。 云效继续交付流水线，收费还好用！云效继续集成流水线 Flow，企业级继续集成和继续交付工具，通过构建自动化、集成自动化、验证自动化、部署自动化，实现从开发到上线CICD过程。通过继续向团队提供及时反馈，让交付过程高效顺畅。

当谈到采纳“继续测试”办法时，所有都与良好的设计无关。测试不再是开发的预先想法（afterthought）。“先写代码再做测试(write-first-test-later )”的心态曾经过期了。为了在您的组织内实现高质量和继续的测试，您在编写代码时必须采纳“测试优先（test-first）”的思维形式。 为了更好地了解组织在继续测试方面所经验的技术和文化转变，最近咱们（DZone）采访了Alan Page (《微软的软件测试之道》作者、行业专家、微软前工程总监和现任Unity Technologies总监，@alanpage / angryweasel.com) ，就继续测试（Continuous Testing，CT）进行了交换，探讨了测试驱动开发的重要性、继续测试常见问题、继续测试的准则、以及AI/ML利用于测试的将来等。 Alan对开发者的倡议： 测试优先的心态。一旦开发人员在编写代码时开始思考测试，他们就会偏向于编写更易于测试的代码。延聘测试专家。不要让测试人员进行测试，而要雇用可能在开发团队中领导并影响测试文化的测试专家（编者注：相当于测试教练，和我之前说的 Test Owner）。100%的测试可自动化。这是最大的测试设计挑战:弄清楚要自动化什么。在UI测试之外，绝大多数测试（编者注：特地是单元测试、集成测试）都能够自动化。防止不稳固的测试。这些测试提供不统一或意外的测试后果。放弃简略。“如果很难进行测试，那么很可能代码不具备可测试性，这才是真正的破绽。” 建设软件品质责任。明确开发人员的职责和责任，容许团队利用继续改良和继续测试准则，这样测试文化就会随着工夫的推移而改良。1、团队实现继续测试（CT）的次要挑战之一是组织外部的技能和人才短缺。您将如何领导团队解决围绕测试的人才短缺问题? Alan：在我职业生涯的过来六七年里，我所做的就是遣散测试团队。不是因为我不喜爱测试员——我已经是一名职业测试员。我发现，特地是在继续交付的团队中(通常是服务组织)，在没有专用测试人员的瓶颈的状况下，软件研发更加高效。但我所做的不是打消（测试人员）而是合成和缩小（测试人员）。我的团队中通常有一些十分优良的测试员，但他们的工作并不是测试，而是为了帮忙开发人员更好地进行测试。 咱们须要解决测试专业化有余的问题，须要在团队的通才中造就测试技能，因而，在我工作的团队中，开发人员要对他们本人的品质和至多90%～95%的测试负责，同时还要对项目管理和交付的其余方面负责。 因而，我的办法是依附开发人员扩大他们的测试技能，并在一些测试专家的帮忙下进行大量的测试。 2、另一个常见的挑战是确定哪些测试要自动化，哪些测试要放弃手动。您的测试自动化的办法是什么，以及决定何时进行手动测试的办法是什么? Alan：我至多在10年前就开始说，应该将 “应该自动化的测试” 100%自动化。这里的逻辑解决测试设计的挑战：找出什么应该被自动化。例如，UI测试不须要做到100%，通常来说，在UI级别和web级别上更难以自动化的。 我通常倡议团队尽可能少地进行手工测试。为了做到这一点，在开发软件时，测试就是软件设计的一个选项，以一种易于应用自动化工具测试的形式创立软件架构。如果软件设计的形式是只能通过手工测试来实现大量的验证，那么咱们可能会陷入极大的窘境。 设计好软件系统，以便它的绝大多数能够通过低级测试（单元测试）进行验证。此外，对于必须手动测试的事件，还须要适当地进行一些检查和均衡，以便可能疾速和轻松地实现测试。我所留神到的，以及我当初教给成千上万的开发人员的，是如何进行良好的测试，一旦开发人员在编写代码时开始思考测试，他们就会偏向于使其所编写代码更具可测试性。 3、咱们发现，“测试文化的变动” 被证实是组织的次要阻碍。对于团队如何克服这些文化阻碍，有什么倡议吗? Alan：归根结底，作为一名开发人员，须要明确本人的职责和任务。我喜爱用团队中为数不多的测试专家来参加研发，目标就是是让他们在团队的品质和测试文化中表演重要角色。咱们能够帮忙推动或驱动这件事，但我和我的开发主管一起做的一件事是：确保每一个开发人员深知他们要对软件的品质和交付负责。我会让公司里有这种特长的人来推动这种文化，而后咱们就尝试并进行继续的改良、继续的实际验证，基于这样的准则，测试文化应该始终变得越来越好。 但咱们必须对人们领有品质的各个方面有一个冀望和责任，这样能力开始建设一种文化，就像其余任何企业文化一样，你要激励那些你想看到的行为。在这样做的过程中，我积攒了一些能源，在整个组织中发明了一种共享的文化。 4、依据您在自动化测试和继续测试方面的教训，您看到过的团队所犯的最大谬误是什么？ Alan： 试图在UI级别实现过多的自动化。这在明天依然是一个问题——尤其是在web空间。我晓得一些次要的应用程序是在web级别齐全应用Selenium进行测试的;只是效率低下。这些测试须要很长时间;它们是片状;团队总是花工夫调试坏掉的测试。这是个很容易掉进的陷阱。测试不稳固。五、六年前，我加入了一个测试自动化会议，仿佛每个演讲都提到了不稳固测试的概念——运行中的测试会给您带来不统一或意外的后果。测试代码试图过于聪慧。如果很难使测试脚本失常运行，那么很可能是代码不具备可测试行，人们喜爱尝试测试脚本中玩一些小动作，这才是真正的Bug。在编写测试时，为了测试而编写简单或难以解决的代码，您可能曾经发现了真正的Bug：这些代码永远不会被保护。重要的是要留神相似的状况，不要为了测试脚本能运行而全力以赴。5、令人诧异的是，十分小比例的受访者(只有8%)示意，他们目前正在应用AI（人工智能）或ML（机器学习）进行CT，回归测试和用户测试用例是次要的局部。在测试中，你认为团队应该在哪里扩大AI/ ML实现? Alan：据我所知，所有应用AI和ML技术的测试工具都在（我之前埋怨过的）UI测试畛域表现出色。导致传统的UI自动化测试不稳固的起因是UI能够挪动、id能够扭转，所有的货色都能够扭转，毁坏你的测试。 在将来的五年里，咱们能够应用AI或ML为咱们生成大量的测试用例。更进一步，如果你能收集理论的客户应用模式——许多公司收集客户如何应用软件的数据——而后将这些数据输出AI/ML模型中来创立变异，就能产生额定的测试用例或测试运行。测试人员痴迷于端到端用户体验测试，比方这个用户工作流是如何工作的，这些测试往往是不稳固的。 然而，如果咱们可能解脱这些新工具中的软弱，联合AI/ML的能力，基于客户数据生成实在场景的测试用例，咱们就能失去一些十分有价值的货色。最初，如果我的疯狂打算停顿顺利，测试人员就不会花任何工夫或很少工夫来编写这些UI测试，而编写测试用例占用了太多的工夫，最初咱们就能失去了更高质量的产品。这就是我心愿的AI和ML方向。 6、在接下来的6-12个月里，你会在哪持续进行测试?你认为对于团队、开发者和管理者来说，为了获得成功，什么是最重要的? Alan：继续测试、继续集成、继续一切都是对于增强反馈循环。继续部署就是要确保咱们能尽快失去对于咱们所构建的货色的反馈。 继续测试确保了咱们所做的每一步都是正确的测试。为了交付任何货色，无论是CI还是客户，无论在哪里，还有很多须要改良的中央。 尽管听起来很现实，但咱们还没到那一步。然而，一直地抉择正确的测试，在正确的工夫运行，不论这些测试是手动的还是主动的，并且减速整个零碎的品质反馈，将加强咱们在所有阶段取得反馈的能力，交付也越来越快。 起源：软件品质报道 作者：DZone 申明：文章取得作者受权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。 5月每周四晚8点，【冬哥有话说】品质与测试专场。公众号留言“品质”可获取地址 0506 朱少民 《如何最大化软件测试效力》0513 陈琦 《数据驱动测试》0520 陈霁 《没错，去QA是提高质量最无效的办法！》0527 施慧斌 《DevOps实际之继续测试》

提到DevOps，很多人就想到了CI/CD Pipeline，甚至很多集体或者企业认为实现了CI/CD Pipeline就等于实现了DevOps，尽管这种观点有失偏颇，然而从侧面反映了CI/CD Pipeline在DevOps中扮演着无足轻重的位置。CI/CD 是DevOps 的两大要害外围能力。CI/CD Pipeline的真正实现会减速企业向DevOps转型的过程。本文将揭开CI/CD Pipeline的神秘面纱，来一探到底。 一、什么是 CI/CD PipelinePipeline 指管道或者流水线，相似于工厂里的生产线，原料从一端输出，两头通过多个工作核心，一个工作核心的输入作为下一个工作核心的输出，最终在另一端输入高质量的产品。CI/CD Pipeline 指CI/CD的流水线，在输出端输出源码，通过既定工作流，最初在输入端输入对用户有价值的产品。从字面就能看出侧重点继续、流水线。 CI/CD Pipeline的简略示意图如下。 开发人员提交完代码，通过一系列的流程，最初生产出有价值的应用程序。 二、为什么须要 CI/CD PipelineDevOps的呈现就是为了解决理论问题：突破横亘于开发人员与运维人员之间的壁垒。CI/CD Pipeline 能够帮忙实现这个目标：开发人员在代码提交之后，就有CI/CD 流程来对所开发代码的功能性，健壮性，安全性等进行验证，如果验证失败，就返回至开发人员处，持续批改；如果通过既定流程，就能够进行生产部署。 当然，整个流程必须是齐备的，测试环节必须是谨严的，开发环境，测试环境，生产环境应尽量保持一致，以此来防止环境不统一导致的上线失败。且整个过程中所有的变更，包含代码变更，部署脚本变更，环境配置变更都是可追踪的，便于呈现问题之后进行回溯与复盘。这样，开发人员就不会放心代码不可能及时部署到生产线，而运维也不用放心新上线的代码会导致系统解体。 此外，CI/CD pipeline 有助于缩短应用程序的公布周期，进步应用程序的公布频率，疾速取得市场反馈，及时作出响应。这种良性循环有助于应用程序抢占市场，给企业带来效益。 《凤凰我的项目: 一个IT运维的传奇故事》中比尔团队的故事就是对上述过程的一个很好佐证：当比尔团队将凤凰我的项目的部署流程梳理分明之后，进行了"流水线"(书中虽不叫CI/CD Pipeline，然而内容却是一样，能够认为是CI/CD Pipeline的雏形)革新，在大大提高凤凰我的项目公布频率的同时，业务部门与IT部门之间的矛盾也变得越来越少，公司盈利了，也就防止公司被拆分，IT部门被外包的危险。 基于此，CI/CD Pipeline 个别具备以下几个特点： 标准化的步骤：应用程序交付流水线中的构建，测试等步骤，一个都不能少，而且环环相扣。可主动部署：从代码提交那一刻起，所有流程都应该是主动的，自动化的益处毋庸置疑：节省时间，缩小人为干涉，防止人为误操作；"一键式"部署让部署变得简略。实用多种语言：CI/CD Pipeline 应该实用于大多数甚至全副语言类型的应用程序，java，php，python。可能只需针对不同语言做大量调整。而不须要每种语言对应本人的CI/CD Pipeline。具备可移植能性：应用程序在不同部署环境下(比方从私有云到公有云，从AWS的Kubernetes 平台到IBM的Kubernetes 平台)迁徙的时候，Pipeline 能够在不改变或者大量改变的前提下，实现迁徙，这样进步了灵活性，缩小了工作量。三、CI/CD Pipeline 蕴含的阶段一般来讲应用程序交付流水线有如下图所示的几个阶段： 3.1 打算阶段此阶段次要是项目经理或产品经理从用户处获取应用程序的相干信息，从而制订开发计划，来对前期开发进行领导。在麻利流行的明天，很多公司在此阶段都用麻利来进行开发治理，以迭代的形式来实现用户故事的开发。 3.2 编码阶段这个阶段次要是开发人员通过IDE来进行代码开发，开发人员借助于装置在IDE内的一些插件，来编写合乎公司编码标准和平安需要的代码。 3.3 构建阶段构建阶段是能够算是CI/CD Pipeline的真正开始阶段，开发人员在本地实现代码开发，并将代码提交到源码管制工具(比方git)，此时会触发CI流程，进行代码扫描，编译，单元测试及覆盖率测试等工作。如果流程是胜利的，那么代码就会被合入主干分支(合并能够是手动，也能够是主动，这取决于我的项目的开发模式与规定)。而一旦某个环节呈现失败，都会使得整个流程中断，并将相应信息反馈至开发人员处。 3.4 测试阶段代码被部署到测试环境并开展一系列的测试工作，包含手动的，主动的；性能的，性能的，平安的。须要留神的是，此阶段测试所需环境最好与生产环境保持一致，防止因环境不统一导致的上线失败。 3.5 版本筹备阶段测试阶段验证胜利当前，能够认为代码已具备上生产的能力，测试通过的版本被标记为能够上生产，只须要手动或者主动操作(取决于我的项目规定)就能够将版本推送至生产线上。 3.6 部署阶段将应用程序部署到生产线上。能够采纳手动或者主动的形式来实现部署，同时能够采纳蓝绿部署，金丝雀部署等形式来实现"零宕机"、平安部署。 3.7 维护阶段应用程序上线后，运维团队须要确保利用程序运行环境的稳固，在访问量高的时刻可能主动扩容来应答峰值，访问量低的时候缩容以缩小资源耗费。 3.8 监控阶段监控应该蕴含两方面的：应用程序的监控和Pipeline的监控，借助于监控工具来获取一些无效数据，而后反馈给开发团队，或者运维团队，以此来进一步提高应用程序及Pipeline的稳定性，安全性。 CI/CD Pipeline 简直等同于应用程序交付流水线，它与之绝对应阶段的关系如下图所示。应用程序交付流程从打算阶段开始，而CI/CD Pipeline开始于利用程序开发阶段。 四、CI/CD Pipeline 的实现CI/CD Pipeline 也能够用三步工作法来实现： ...

继续交付能力1.对所有生产工件应用版本控制版本控制是将所有生产工件纳入版本控制系统（例如GitHub或Subversion）治理，包含利用程序代码，应用程序配置，系统配置以及用于主动构建和配置环境的脚本。 2.自动化部署过程部署自动化是指部署齐全自动化且不须要人工干预的水平。 3.施行继续集成继续集成（CI）是实现继续交付的第一步。这是一种开发实际，其中的代码会定期检入，每次检入都会触发一组疾速测试，以发现重大的回归问题，开发人员会立刻对其进行修复。CI流程将创立标准的构建和程序包，并最终进行部署和公布。 4.应用基于骨干开发方法基于骨干的开发模式已被证实能够实现软件开发和交付中的高性能。它的特点是在代码存储库中少于三个流动分支。在合并入主干分支之前具备十分短的生命周期（例如，少于一天）的分支；应用程序团队很少或素来没有“code lock”期，因为合并抵触，代码解冻或稳固阶段，没人能签入代码或执行拉取申请。 5.施行测试自动化测试自动化是一种在整个开发过程中主动（而非手动）间断运行软件测试的实际。无效的测试套件是牢靠的，也就是说，测试会发现真正的失败，并且只能通过可公布的代码。请留神，开发人员应次要负责创立和保护自动化测试套件。 6.反对测试数据治理测试数据须要认真的保护，并且测试数据治理已成为自动化测试中越来越重要的局部。无效的做法包含领有足够的数据来运行您的测试套件，按需获取必要数据的能力，在管道中对测试数据进行条件调整的能力以及不限度能够运行的测试数量的数据。然而，咱们的确要正告，团队应尽可能减少运行自动化测试所需的测试数据量。 7.左移安全性将安全性集成到软件开发过程的设计和测试阶段是进步IT性能的要害。这包含对应用程序进行平安审查，包含在应用程序的设计和演示过程中的信息安全团队，应用事后批准的安全性库和程序包，以及将安全性性能作为自动化测试套件的一部分进行测试。 8.施行继续交付（CD）CD是一种开发实际，其中软件在其整个生命周期中都处于可部署状态，并且团队优先思考使软件放弃在可部署状态，而不是钻研新性能。所有团队成员都能够疾速取得无关零碎品质和可部署性的反馈，当他们收到无关零碎不可部署的报告时，能够疾速进行修复。最初，能够依据须要随时将零碎部署到生产或最终用户。 架构能力9.应用松耦合的架构这影响了团队能够按需测试和部署其应用程序的水平，而无需与其余服务进行协调。涣散耦合的架构使您的团队可能独立工作，而无需依赖其余团队的反对和服务，从而使他们可能疾速工作并为组织发明价值。 10.受权团队的架构师咱们的钻研表明，能够抉择要应用哪些工具的团队在继续交付方面会更好，进而能够推动更好的软件开发和交付性能。没有人比从业者更分明他们须要什么能力无效。 产品和过程能力11.收集并施行客户反馈咱们的钻研发现，组织是否定期被动地寻求客户反馈，并将此反馈纳入其产品设计对软件交付性能很重要。 12.通过价值流使工作流程可见团队应该对从业务始终到客户的工作流程有很好的了解和可视性，包含产品和性能的状态。咱们的钻研发现，这对IT性能有踊跃影响。 13.小批量工作团队应该将工作分成小块，能够在一周或更短的工夫内实现。要害是将工作合成为容许疾速开发的小性能，而不是在分支上开发简单的性能并很少公布它们。这个想法能够利用于性能和产品级别。（MVP是产品的原型，具备足够的性能以使人们可能无效地理解产品及其商业模型。）小批量工作可缩短交货工夫并放慢反馈循环。 14.造就和启用团队试验团队试验是开发人员在开发过程中尝试新想法并创立和更新标准的能力，而无需团队内部的批准，这使他们可能疾速翻新并发明价值。当与小批量工作相结合，合并客户反馈并使工作流程可见时，这特地有影响。 精益治理和监控能力15.进行轻量级变更批准流程咱们的钻研表明，与应用内部变更批准委员会（CAB）相比，基于同级审查（对编程或团队外部代码审查）的轻量级变更批准过程可产生杰出的IT性能。 16.跨应用程序和基础架构进行监督以告诉业务决策应用来自应用程序和基础架构监督工具的数据来采取行动并制订业务决策。当呈现问题时，这不仅仅能够传呼他人。 17.被动查看零碎运行状况应用阈值和变化率正告来监视系统运行状况，以使团队可能领先发现和缓解问题。 18.改良流程并治理在制品（WIP）限度的工作在精益社区中，应用在制品限度来管理工作流程是家喻户晓的。无效应用后，可进步流程效率，进步吞吐量并在零碎中显示束缚。 19.可视化工作以监督品质并在整个团队中进行沟通已显示用于监督品质和在制品的视觉显示，例如仪表板或外部网站，有助于软件交付性能。 文化能力20.反对生成文化掂量组织文化的根据是社会学家罗恩·韦斯特鲁姆（Ron Westrum）开发的一种类型学，他在航空和医疗保健畛域钻研了对平安至关重要的简单零碎。咱们的钻研发现，这种文化水平能够预测IT绩效，组织绩效和缩小倦怠。此措施的标记包含良好的信息流，高度的单干与信赖，团队之间的桥梁以及无意识的询问。 21.激励和反对学习在您的文化中，学习被认为对继续提高至关重要吗？学习被视为老本还是投资？这是对组织学习文化的一种掂量。 22.反对和促成团队之间的单干这反映了传统上孤立的团队在开发，经营和信息安全方面的互动水平。 23.提供使工作有意义的资源和工具。这项工作满意度的非凡衡量标准是从事具备挑战性和有意义的工作，并有权锤炼您的技能和判断力。这还与取得做好工作所需的工具和资源无关。 24.反对或体现改革型领导改革型领导反对并扩充了DevOps中至关重要的技术和流程工作。它由五个因素组成：视觉，智力刺激，鼓励性沟通，支持性领导和集体认可。 起源：DevOps云学堂 摘自Nicole Forsgren博士，Jez Humble和Gene Kim 的Accelereate摘录 4月每周四晚8点，【冬哥有话说】DevOps之庖丁解牛，拆解DevOps的工具及具体实战。公众号留言“解牛”可获取地址 0401《数据库继续交付流水线分享与演示（Azure DevOps+Flyway）》0408《继续交付中的版本治理与基于Azure DevOps扩大框架的插件开发》0428（周三）《微服务，多团队合作中的API测试怎么做 - Pact契约测试》0429（周四）《BoatHouse端到端流水线展现》

作者：Tracy Miranda 人们总是问我为什么CD.Foundation不是CICD Foundation，我必须更好地答复这个问题。第一步是探讨CI/CD这个被误导的词到底是什么。 这让新来者感到困惑 我已经认为CI/CD中的“D”代表“Deployment（部署）”，但在过来的3年里，越来越多的人仿佛用它来示意“Delivery（交付）”。在2020年FOSDEM上，有一个CI/CD分论坛，“D”是代表“Deployment（部署）”。在我的演讲中，我问观众他们的想法，后果令人捧腹。 这让行业专业人士感到困惑 Owen Adams，咱们的一位CDF大使，就平台工程、软件工程和治理方面的角色采访了一些从业者。他采访了76名候选人，询问他们对于继续交付和继续部署之间的区别。尽管多数人能分明地说出这一点，但绝大多数人（75%）甚至没有意识到其中的区别。 行业专家厌恶这个词 让咱们只是说，它使Jez Humble感到无奈。 这是一个误导人的术语 CI/CD意味着某种阴阳，兴许这两种货色是等价的，同时存在，或者一个先呈现，另一个先呈现。它提供了一种过于简化的办法：先执行CI，而后执行CD（无论这意味着什么），而后实现了交付软件的工作，你就能够自我褒扬了。 事实上，继续交付是一组实际，使咱们可能无效地向用户交付软件变更。继续集成只是继续交付伞下的一种实际。其余实际包含版本控制、部署自动化、测试自动化、平安实际等。 Christie Wilson的钻研表明，CI/CD这个词是在2013年有机地呈现的。毫无疑问，在过后它很吸引人，很有用，足以定义整个行业。 我不抱任何空想，CI/CD一词将很快隐没。然而，随着软件向微服务、解释语言（如Python）等倒退，CI的角色将产生巨大变化，这将使术语“CI/CD”越来越不合乎时代要求。特地是对于那些真正想在古代时代更好地交付软件的人来说。 感激以下审阅这篇文章的人： Owen Adams、Christie Wilson、Mauricio Salatino、Roxanne Joncas 加入10月7日的_CDCon_第一场主题演讲“继续交付的过来、当初和将来”，我、Christie Wilson（谷歌）和Zainab Abubakar（She Code Africa）带你踏上CD之旅。 点击浏览网站原文。 为下一代继续交付合作提供一个中立的家。 CDF（Continuous Delivery Foundation，继续交付基金会）是许多快速增长的继续交付我的项目，包含Jenkins、Jenkins X、Spinnaker和Tekton，的供应商中立家园。CDF通过凋谢模型、培训、行业指南和可移植性重点来反对DevOps从业者。 Linux基金会是非营利性组织，是技术生态系统的重要组成部分。Linux基金会通过提供财务和智力资源、基础设施、服务、流动以及培训来反对创立永续开源生态系统。在共享技术的创立中，Linux基金会及其我的项目通过共同努力造成了不凡胜利的投资。扫描二维码关注LFAPAC微信公众号。

如果开发人员的变更集在集成时并没有实现长期部署就绪的状态，那么你的团队其实就没有真正的实践持续交付。 想要完全优化产品开发周期，你需要在团队中强调无缝部署的重要性，使每位工程师都对主要生产线负责，使主要生产线保持在可发布状态。 真正的持续交付中很多团队大概率都会遇到的以下三类阻碍： 实施过程：你的开发过程中存在很多人为制造的阻碍，包括质量检查和手动部署。操作推进：你的经理或工程师缺乏信心。他们不确定是否能够在集成前发现系统漏洞，或无法确定能否应对那些系统部署后才发现的问题。技术工具：你现在所用的开发工具不充分、效率太低或者经常出故障。这篇文章将会告诉你如何降低每一类障碍，从而在你的工程师团队中实现部署就绪文化。 01实施过程中的阻碍在团队从传统交付状态过渡到持续交付的过程中，需要开发团队中的每个人都尽可能有策略地管理时间。实现这种严苛的时间管理方法的前提就是要在部署过程中尽可能地自动执行所有操作，尤其是那些非常阻碍部署的手动操作。在许多团队中，最困难的实施障碍不只单单存在于人力管理和发布流程管理（例如人工质量检查和安全检查）。持续交付工程中代表“批准许可”标志的存在会让团队有信心相信他们交付的产品是符合要求的。因此，解决软件开发工程中的品控问题不能是只放在最后一步实施的，在每个环节都进行严格把控是消除流程实施中的障碍最关键的一步。 | 移除部署过程中的障碍——QA（质量测试） | 无论是手动还是自动，测试的目的是确保软件质量符合标准。持续交付中的许多操作，例如小批量工作和代码审查，都自带质量管控监测的特性。任何在开发过程中没有被团队所发现的重大缺陷都应该通过自动检测来发现。 为了降低因QA带来的风险，你的团队应该： 在整个开发过程中采用自动化测试（而不仅仅是在最后一步）。虽然在哪里测试以及测试对象取决于各种各样的因素，但将测试尽早融入到开发过程中，能够有效防止在开发者投入大量工作之前及时发现问题。不要过度测试。过度测试可能会导致过长的构建时间，并且会制造出自动化瓶颈。我们建议你应确保测试的范围充分，这样一来如果系统在半夜里出了故障，你们也无需叫醒工程师来处理。使用特性切换和灰度发布。如果系统中存在尚未解决的部署风险，请使用特性切换在内部或对少量客户群样本进行更改。如想进一步了解相关研究，请查看Launch Darkly关于有效特性管理的完整版电子书。满足以上三种要求之后，还将需要确保系统中存在有效的检测系统，这样做有一个很大的好处就是让你的系统能够及早显现出目前所存在的问题。故障诊断所需平均时间（MTTD）和故障恢复所需平均时间时间（MTTR）将帮助你持续跟踪并提高管控和部署前测试套件的效率。 | 安全合规检查 | 安全检查是部署前最重要的检查之一，这就是为什么安全检查不能容忍人为错误。你团队的安全专家应该策略性地考虑应该进行哪种测试，同时将大部分战略性的安全工作留给计算机去完成。 如果你的团队想把安全性全程融入到软件交付的过程中，你应考虑如下操作： 让团队中的安全专家参与软件规划和设计过程。每当处理特别敏感数据的功能在持续交付流程中减弱时，请在计划和设计过程中让你的安全团队参与进流程中来。这样，在你的团队构建功能时，安全注意事项就融入了整个流程并成为团队的首要考虑因素。自动源代码扫描（SAST）：由于80％的攻击针对应用程序层，SAST一直是确保应用程序安全的最佳方法之一。自动化的SAST工具可检测所有最具威胁性的应用程序风险，例如身份验证失败，敏感数据暴露和配置错误。自动化动态测试（DAST）：通常被称为黑盒测试，这些测试试图从外部渗透应用程序。任何DAST工具都会帮助发现两个最常见的风险 -- SQL注入攻击（SQLi）和跨站脚本攻击（XSS）。依赖于常见漏洞（CVE）的自动测试：CVE是由网络安全局和基础结构安全局维护的代码字典，你可以把CVE作为参考，以确保你的自动测试涵盖了足够的范围。为团队构建安全且可重用的基础架构。在实现了上面的几项操作之后，你的安全团队可以运用他们的专业知识，以模块或原语的形式为团队创建工具。这样一来，未经过安全培训的开发人员也能够编写出默认为安全的系统。安全团队的工作不能完全由机器代替，例如渗透测试。但是，如果你将安全性纳入整个开发流程中，人为工作便不会在开发流程的最后阶段成为瓶颈，导致功能无法推向客户。 02 克服操作过程中的障碍在DevOps Group进行的一项调查中发现，组织文化是CD实施的最大障碍。构建持续交付文化所需的工作模式/行为改变是适应真正的CD实践最困难、但讨论最少的方面。你的团队需要有信心，他们的测试基础架构和响应变更的能力都应该足够强大，能够支持持续部署。为了像团队输出这种确定性想法，你需要围绕CD的优势进行调整，并在整个软件交付过程中鼓励最佳实践。 | 建立持续交付的组织一致性| 如果沟通得当，那么持续交付对工程师而言不应该是一个难以接受的事情。CD可以使开发人员做他们最喜欢的事情-构建有用的软件并将其推向世界。以下三个预期结果将帮助管理人员和工程师都投入到持续交付中: 让项目整体风险减低——如果测试基础架构是可靠的（下面有更多关于这一点的内容），并且开发人员也同意该基础结构的可靠性，那么即便在程序发布后有需要更改也变得更加轻松。对单个开发人员的影响更大——当开发人员有权参与到产品生产中时，他们会感到对工作拥有更多的所有权。由于对速度的期望，持续交付使自上而下的计划周期变得更加精细，并使开发人员能够做出更多与功能实现相关的选择。团队间抱怨与指责会减少—— 因为对某个功能的所有权不会单独集中在一个人身上，所以软件开发过程变得更加需要团队成员彼此之间的协作。当开发人员决定将他们的更改发布到产品中时，功能的“分布式”所有权会消除掉一部分由于功能更改上线带来的焦虑和潜在可能出现的“责备”。| 为你的团队提供最佳实践的变革 | 到目前为止，我们的_“缩短项目周期的战术指南”（ Tactical Guide to a Shorter Cycle Time five-part series ）_共分五部分，其中包括数十种可以与团队共享的最佳实践。除了这些特定阶段的优化之外，你还需要以下这些通用原则的指导： 在小而离散的变化中工作——当开发人员确定“Pull请求”时，他们应该思考“我可以为实现此功能而采取的最轻巧且有价值的步骤是什么？”当他们确定范围并构建了“Pull请求”后，应将其部署到生产环境中。他们应该避免长时间运行功能分支。始终优先考虑最接近完成的工作—— 让开发人员尽可能地减少进行中的工作。如果你在使用看板图，则意味着你要对最接近完成的项目进行优先排序。如果这个过渡过程需要超过6个月的时间，请不要感到惊讶。你的团队需要很长时间才能建立起对这种新的工作方式习惯的信心。如果你想要快速地采取行动，请与一群已经有兴趣并且乐于做出积极改变的早期探索者来一起研究、使用CI/CD。相比于大环境，你反而可以在小而精的组织环境中更好地学习、打磨新的模式。 03 克服技术工具相关障碍即便你的团队对于自己的CI/CD工具套件充满了信心，仍然需要面对工作习惯、流程及沟通上的困难。 | 优化你的工具 | 如果有出现以下情况中的任意一个，那么你就不能每天多次向客户发布功能: 1、你的软件版本很不稳定 2、你的软件版本速度非常缓慢即使你的测试通过了，但团队也没有信心设置自动部署，如果: 1、你的监测不彻底 2、你的检测结果没有得到很好的调整这里提供一种我们觉得比较安全的测试方法：使用灰度测试。团队在这种情况下既能够测试问题的捕捉速度和恢复速度，同时又不会损害客户体验。当你努力改进测试版本和监控过程时，我们建议你慢慢地将手动部署过渡到更频繁的节奏。首先可以从每周部署开始，然后是每天，再然后是一天多次部署。最后，当你一旦按下部署按钮就感觉很浪费时间时，那就可以进入自动化部署过程了。 04 软件交付的“圣杯”通过以上内容的介绍，如果你的团队成功实现了持续交付，那么开发人员将在几乎不会产生冲突的情况下通过持续交付的pipeline实现软件的细微增量更改、版本迭代及持续推送。但是，除非你实际将这些更改/更新交付到客户手中，否则你就不算是真正实践了持续交付。CD（以及之前的敏捷）的重点是缩短客户与工程师之间的反馈循环。以增量的方式工作，但如果仍在发布大量版本，就没有办法实现这个目标。持续交付需要以减少风险、快速响应，并尽可能快地将软件的最佳版本交付给客户。 原文链接：https://hackernoon.com/the-last-mile-to-true-continuous-delivery-6sk323j 以上信息来源于网络，由“京东智联云开发者”公众号编辑整理，不代表京东智联云立场 欢迎点击“京东智联云”了解更多精彩内容！