持续交付

最近某位大神在推特上发了一个帖子，后果引来了国内泛滥卖课机构、培训机构的狂欢，开始贩卖焦虑，其实「平台工程」也不是什么特地高深莫测的货色。闲得无聊，把这位大神的几个帖子薅了下来，你看过之后就会感觉也没啥，都是相熟的货色。 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 以上信息来源于网络，由“京东智联云开发者”公众号编辑整理，不代表京东智联云立场 欢迎点击“京东智联云”了解更多精彩内容！

导读：云原生时代，Kubernetes 的重要性日益凸显。然而，大多数互联网公司在 Kubernetes 上的探索并非想象中顺利，Kubernetes 自带的复杂性足以让一批开发者望而却步。本文中，阿里巴巴技术专家孙健波在接受采访时基于阿里巴巴 Kubernetes 应用管理实践过程提供了一些经验与建议，以期对开发者有所帮助。在互联网时代，开发者更多是通过顶层架构设计，比如多集群部署和分布式架构的方式来实现出现资源相关问题时的快速切换，做了很多事情来让弹性变得更加简单，并通过混部计算任务来提高资源利用率，云计算的出现则解决了从 CAPEX 到 OPEX 的转变问题。 云计算时代让开发可以聚焦在应用价值本身，相较于以前开发者除了业务模块还要投入大量精力在存储、网络等基础设施，如今这些基础设施都已经像水电煤一样便捷易用。云计算的基础设施具有稳定、高可用、弹性伸缩等一系列能力，除此之外还配套解决了一系列应用开发“最佳实践”的问题，比如监控、审计、日志分析、灰度发布等。原来，一个工程师需要非常全面才能做好一个高可靠的应用，现在只要了解足够多的基础设施产品，这些最佳实践就可以信手拈来了。但是，在面对天然复杂的 Kubernetes 时，很多开发者都无能为力。 作为 Jira 和代码库 Bitbucket 背后的公司，Atlassian 的 Kubernetes 团队首席工程师 Nick Young 在采访中表示： 虽然当初选择 Kubernetes 的战略是正确的（至少到现在也没有发现其他可能的选择），解决了现阶段遇到的许多问题，但部署过程异常艰辛。那么，有好的解决办法吗？ 太过复杂的 Kubernetes“如果让我说 Kubernetes 存在的问题，当然是‘太复杂了’”，孙健波在采访中说道，“不过，这其实是由于 Kubernetes 本身的定位导致的。” 孙健波补充道，Kubernetes 的定位是“platform for platform”。它的直接用户，既不是应用开发者，也不是应用运维，而是“platform builder”，也就是基础设施或者平台级工程师。但是，长期以来，我们对 Kubernetes 项目很多时候都在错位使用，大量的应用运维人员、甚至应用研发都在直接围绕 Kubernetes 很底层的 API 进行协作，这是导致很多人抱怨 “Kubernetes 实在是太复杂了”的根本原因之一。 这就好比一名 Java Web 工程师必须直接使用 Linux Kernel 系统调用来部署和管理业务代码，自然会觉得 Linux “太反人类了”。所以，目前 Kubernetes 项目实际上欠缺一层更高层次的封装，来使得这个项目能够对上层的软件研发和运维人员更加友好。 如果可以理解上述的定位，那么 Kubernetes 将 API 对象设计成 all-in-one 是合理的，这就好比 Linux Kernel 的 API，也不需要区分使用者是谁。但是，当开发者真正要基于 K8s 管理应用、并对接研发、运维工程师时，就必然要考虑这个问题，也必然要考虑如何做到像另一层 Linux Kernel API 那样以标准、统一的方式解决这个问题，这也是阿里云和微软联合开放云原生应用模型 Open Application Model （OAM）的原因。 ...

Github travis-ci CI CDCICD 是 持续集成Continuous Integration和持续部署Continuous Deployment简称。指在开发过程中自动执行一系列脚本来减低开发引入 bug 的概率，在新代码从开发到部署的过程中，尽量减少人工的介入。 本文主要介绍一下 travis-ci 持续集成和给 github Actions Travis-cihttps://www.travis-ci.org/1.登录travis-ci通过 github账号登录,会自动同步你的仓库 选择需设置的仓库 先勾选一个测试仓库 3 设置一些解释说明可以看具体的文档,主要包括这几方面 添加.travis.ymlTravis-ci 构建的生命周期 具体一些步骤可以查看文档. 这个文件主要是告诉 Travis CI 应该做什么,以前端node.js为例: language: node_js # 语言设置node_js: # node 版本 - "8"# npm现在默认缓存，如果您要禁用它，请将以下内容添加到您的.travis.yml：cache: npm: false before_install: # 安装前 - npm installscript: - npm run build如果当前目录存在yarn.lock可以使用 Yarn; 如果当前目录中都存在package.json和yarn.lock，则运行以下命令而不是 npm install 具体的一些配置,通过查看文档即可; 现在已经构建成功; 发布部署如果每次构建完都自动部署,或者手动部署可以再下一步; language: node_jsnode_js: - "8"before_install: - yarn installscript: - yarn build after_script: - cd ./dist - git init - git config user.name "${U_NAME}" - git config user.email "${U_EMAIL}" - git add . - git commit -m "Update tools" - git push --force --quiet "https://${GH_TOKEN}@${GH_REF}" master:${P_BRANCH}#指定分支，只有指定的分支提交时才会运行脚本branches: only: - master发布的是 github page 博客. ...

本文先介绍了系统构建的先决技术与实践，自动化构建、版本控制，并给出了Java环境下一些构建工具，然后分别介绍了持续集成（CI）、持续交付和持续部署（CD）的概念及其优势，并在最后给出了一些最佳实践，如确保部署一致、保证良好的测试覆盖率等。 现代软件开发的需求加上部署到不同基础设施的复杂性使得创建应用程序成为一个繁琐的过程。当应用程序出现规模性增长，开发团队人员变得更分散时，快速且不断地生产和发布软件的流程将会变得更加困难。 为了解决这些问题，开发团队开始探索新的策略来使他们的构建、测试和发布流程自动化，以帮助其更快地部署新的生产。这就是持续交付和持续集成发展的由来。 本文将介绍什么是CI/CD并且它是如何帮助团队迅速开发部署经过充分测试、可靠的软件。在了解CI/CD及其优势之前，我们应该讨论这些系统构建的一些先决技术和实践。 自动构建流程 在软件开发过程中，构建流程会将开发人员生成的代码转换为可执行的可用软件。对于Go或者C语言等编译语言，此阶段需要通过编译器运行源代码以生成独立的二进制文件。对于Python或PHP等解释性语言，没有编译的步骤，但是代码依旧需要在特定的时间内冻结、绑定依赖项、打包以便于分发。这些过程通常称为“构建”或“发布”的工件。 虽然开发人员可以手动构建，但这样操作有诸多不利。首先，从主动开发到创建构建的转变中引入了上下文转换，使得开发人员不得不停止生产效率更高的工作来专注于构建过程。其次，每个开发人员都在制作自己的工件，这可能导致构建过程不一致。 为了解决这些顾虑，许多开发团队配置了自动构建流水线。这些系统监视源代码存储库，并在检测到更改时自动启动预配置的构建过程。这一配置无需牵涉过多的人力在其中并且确保了每个构建过程一致。 市场上有许多帮助用户自动化这些步骤的构建工具，以下列出了在Java生态下比较受欢迎的构建工具： Ant：Apache Ant是一个开源Java库，创建于2000年。它是Java领域的原始构建工具，至今仍然被频繁使用。Maven：Apache Maven是一个自动化构建工具，主要是为Java项目编写的。不同于Apache Ant，Maven遵循约定优于配置的原则，仅需要针对偏离合理默认值的构建过程的方面进行配置。Gradle：在2012年推出的1.0版本中，Gradle尝试通过结合Maven的现代功能来融合Ant和Maven的优势，同时又不失Ant提供的灵活性。构建指令是用一种名为Groovy的动态语言编写的。尽管在这个领域，这是一个相对比较新的工具，但它已被广泛采用。版本控制 大部分现代软件开发需要在共享的代码库中进行频繁协作。版本控制系统（VCS）用于帮助维护项目历史记录，并行处理离散特征，以及解决存在冲突的更改。VCS允许项目轻松采用更改并在出现问题时回滚。开发人员可以在本地计算机上处理项目，并使用VCS来管理不同的开发分支。 记录在VCS中的每个更改都称为提交。每个提交都对代码库的更改进行编目分类，元数据也包含在其中，例如关于查看提交历史记录或合并更新的描述。 图1 分布式版本控制 虽然版本控制是一个十分有价值的工具，它能帮助管理在单一代码库中许多不同的更改。但分布式开发通常会为其带来挑战。在没有定期合并到共享集成分支的情况下在代码库的独立分支中进行开发可能会使以后合并更改变得困难。为了避免这一情况，开发人员开始采纳持续集成实践。 持续集成（CI） 持续集成（CI）是一个让开发人员将工作集成到共享分支中的过程，从而增强了协作开发。频繁的集成有助于解决隔离，减少每次提交的大小，以降低合并冲突的可能性。 为了鼓励CI实践，一个强大的工具生态已经构建起来。这些系统集成了VCS库，当检测到更改时，可以自动运行构建脚本并且测试套件。集成测试确保不同组件功能可以在一个组内兼容，使得团队可以尽早发现兼容性的bug。因此，持续集成所生产的构建是经过充分测试的，并且是完全可靠的。 图2 持续集成的过程 持续交付和持续部署（CD） 持续交付和持续部署是在构建持续集成的基础之上的两种策略。持续交付是持续集成的扩展，它将构建从集成测试套件部署到预生产环境。这使得它可以直接在类生产环境中评估每个构建，因此开发人员可以在无需增加任何工作量的情况下，验证bug修复或者测试新特性。一旦部署到staging环境中，就可能需要进行额外的手动和自动测试。 持续部署则更进一步。一旦构建在staging环境中通过了自动测试，持续部署系统将会自动将它部署到生产服务器上。换言之，每个通过测试的构建都是实时的，可供用户及早反馈。这使得团队可以不断发布新特性和修复bug，并以其测试流程提供的保证为后盾。 图3 CI / CD流程路线图 CI/CD的优势 持续集成、交付和部署对软件开发过程有显著的改进。下文将简单介绍一些CI/CD的主要优势： 快速反馈回路 对于一个快速的开发周期，快速反馈回路显得尤为重要。为了能够实时接收反馈，软件必须迅速触达终端用户。而CI / CD可以通过简化更新生产部署来提供实现此目标的平台。通过要求每个更改都经过严格的测试，CI可以帮助降低每个构建的相关风险并因此使得团队可以便捷地向用户发布有价值的特性。 增加可见度 CI/CD通常是指将IT流程的各个步骤按序列组成一条流水线，且该流水线对整个IT团队（包括开发、测试、运维等团队）均可见。因此，每个团队成员可以跟踪系统中的构建状态并且可以确定任何导致测试失败的构建。团队成员通过深入了解代码库的当前状态，可以更轻松地规划最佳行动方案。这样的可见度为这一问题提供了一个明确的答案——“我提交的更改是否破坏了构建？” 简化故障排除 尽管CI的目标是集成并测试每个发生在代码库中的更改，但是更安全的方式是每次提交都是小型的并尽早将它们合并到共享代码存储库中。如此，当找到bug时，确定和问题相关的更改会更加容易。毕竟，根据问题的严重程度，团队可以选择回滚或编写并提交修复，从而减少生产中解决问题的时间。 软件质量更高 自动化构建和部署流程不仅缩短了开发周期，而且帮助团队开发出品质更好的软件。因为每个更改都会经过充分的测试并且至少会部署在一个预生产环境中，因此团队可以毫无顾虑地将更改部署到生产中。不过，只有当代码库的所有级别，从单元测试到更复杂的系统测试，都有良好的测试覆盖率时，才能实现这一点。 集成问题更少 因为自动化测试套件在每次提交时自动生成的构建上运行，所以可以尽早检测并修复集成问题。这使开发人员能够及早了解当前正在进行的工作是否可能影响其代码。它会在一开始就测试由不同贡献者编写的代码是否兼容，而不是在之后可能出现其他问题的时候才开始测试。 有更多的时间专注于开发 CI/CD系统依赖自动化来生产构建并且通过流水线来迁移新的更改。由于不需要手动干预，因此构建和测试不再占用开发团队大块的时间。进而开发人员可以心无旁骛地对代码库进行有效的更改，因为如果构建过程中出现任何问题，自动化系统会通知他们。 持续集成和交付的最佳实践 既然我们已经了解了使用CI/CD的一些优势，那么接下来，我们将讨论一些指导原则来帮助您成功实现这些流程。 对CI / CD流水线负责 开发者直到更改被部署到预生产环境中，才无需对其提交的代码负责。这意味着开发者必须确保他们的代码集成正确并且随时可以部署。如果提交的更改违反了这些要求，则开发人员有责任快速提交修复以避免影响其他人的工作。构建失败应该暂停流水线并阻止不参与修复故障的提交，这使得快速解决构建问题变得至关重要。 确保部署一致 部署过程不需要手动操作，反而流水线需要自动部署流程以确保一致性和可重复性。这减少了将破坏性构建推向生产的可能性，并有助于避免出现一些难以重现的、未经测试的配置。 将代码库提交到版本控制 将每次更改提交到版本控制是十分重要的。这会帮助团队审核所有提交的变更并且让团队可以简单地还原出现问题的提交。同时，也可以保持配置、脚本、数据库和文档的完整性。如果没有版本控制，特别是当多人使用同一个代码库时，会非常容易丢失配置和代码更改或对其处理不当。 提交小的、渐进的更改 开发人员一定要牢记：更改必须是小的。因为等待引入更大批量的更改会延迟测试反馈，会更难以确定问题的根本原因。 良好的测试覆盖率 由于CI / CD的目的是减少手动测试，因此整个代码库应该有一个良好的自动化测试覆盖率，以确保软件按预期运行。此外，还应该定期清理冗余或过时的测试以避免影响流水线。 ...

阿里妹导读：业务的快速发展，需要我们更快速地响应，和更高质量产品的交付。如何从原来大(xiao)迭(pu)代(bu)的开发模式切换为精益开发模式？以 2-1-1（2周需求交付周期，1周需求开发周期，1小时集成时长）为愿景驱动改进，达到持续交付价值，响应业务要求成为我们的目标。今天，闲鱼工程师琪钰为我们分享：闲鱼是怎样朝着这一目标前进的？切换为精益开发模式后，又面临了哪些问题和挑战？名词解释：精益开发模式，团队基于看板组织协作，以持续地交付需求为目标，需求按优先级，逐步进入开发、提测。由于在项目协作中，采用看板泳道来管理需求，因此在闲鱼，同学们习惯称之为泳道模式。 1、我们面临的要求和挑战业务对交付响应时间要求越来越快。闲鱼业务正处于高速发展中，反摩尔定律告诉我们，交付越迟，商品价值打折得就越厉害。速度为王，为了满足业务快速迭代和试错对技术团队能否快速交付需求提出了更大的挑战。团队规模变大，项目沟通成本越来越高。随着闲鱼业务和技术的快速发展，交付的环境也越来越复杂，协作的角色越来越多。整个研发过程包含需求管理、开发、测试、发布、回归等关键活动，涉及aone（研发协作平台，主要是需求、bug管理等）、代码库、打包平台、自动化测试平台等多个系统，沟通协同的成本越来越高。多分支并行开发增加额外成本。项目开发切换为精益开发模式最核心的改变就是各需求是独立的互不影响，可以分别独立进行测试和集成，保持主干的稳定，随时拉发布分支进行灰度发布。但多分支并行开发，也带来了新的问题，原来打包配置、手动打包、安装测试包等人工成本，都成倍的增加。随时来的提测都能够测。之前客户端发布版本时间固定，批量开发、批量提测，测试介入比较晚。项目开发切换为精益开发模式对技术质量团队提出了更高的要求，面对多需求同时提测的情况，如何更快地响应测试。所以，构建一个贯穿从需求到代码开发，再到测试整个过程的流程，并将其工具化、自动化就显得十分必要和紧迫，而持续集成就是这一流程的重要形式体现，构建一个高效的持续集成系统摆在我们面前。这将一定程度降低开发过程中的沟通成本，流程工具化，加速自动化。 现在针对服务端的集成发布有很多可以参考的实践，但对客户端的集成发布来说，我们依然面对如下难点。 2、客户端持续集成的难点如何将研发过程中各环节关联起来，一个需求从创建到发布的关键活动如下：创建需求->创建代码分支->创建打包项目->提交代码->打包->提交测试->修复->提交集成->发布如何做到需求和代码分支关联，确保代码可追溯； 如何做到代码分支和打包项目关联，代码变更可自动触发打包； 如何做到代码范围和测试范围关联，确保测试回归范围。 多分支并行，如何有条不紊的进行集成。并行需求分支越多，意味着提交集成时，可能的冲突的概率就会越大。如何降低集成的冲突，以及集成后主干的稳定性，确保集成质量；如何做到一提交代码就触发测试，测试进一步左移；如何降低自动化测试的成本，提高测试效率；而要解决上面的这些难点，缺少一站式的工具平台支撑（集团内平台对服务端的发布有很好的支持，但对于客户端的集成发布来说，涉及平台工具比较多）。 3、怎么做客户端持续集成为了解决从需求创建到发布整个项目研发过程中协同、构建、集成和测试等遇到的问题，提高团队的持续交付能力。针对客户端集成发布，我们的整体方案的目标是首先是拉通整个需求交付流程中各个环节，简化持续交付工作，提供及时的质量反馈机制，让开发同学关注在业务的开发；有效提高集成成功率及缩短集成发布周期，让版本能够按时上线大家能够按时下班；建设可视化、自动化、智能化的持续集成流水线，让业务需求真正的可持续交付。 空谈误国，实干兴邦。在谈论更多的改进之前，我们先把基础本的流程通过工具先串起来，只有先看到整体，然后再发现问题逐步改进。 流程化 我们的核心流程是这样的，一旦创建需求分支，交付通道就已建立，直到需求发布。 首先开发按照规范创建需求分支后，自动将分支和需求进行绑定，同时创建打包项目后，自动将需求和打包地址进行绑定，这样开发同学一旦提交代码，就可以根据需求、代码提交内容等，给出影响范围，同时自动触发打包，开发和测试同学不用再担心最新的包中是否有刚提交的内容，每次变更都会触发打包；打包成功后，根据 merge request、push 定时等不同的触发方式，及分支类型，自动触发相应的测试件，进行一系列的自动化测试；测试件执行完后，执行结果将被及时反馈出来，确保每次代码变更都是经过测试验证的，测试进一步左移，并将问题在团队项目协作看板上将问题标示出来，帮助团队在项目协作中能够持续的发现问题从而提高集成质量，降低发布风险，保证业务更快更顺畅的交付。当完成了第一步，将整个流程打通之后，我们发现，在整个流程中，依然有很多是依赖人工操作的地方，这是最容易出错，并且极低地影响效率的地方，对我们来说，这是改进的机会，所以，第二步我们的重点就是做好无人化和自动化。 无人化 为了支撑持续集成流水线的运行，以无人化、自动化、可扩展为目标，及基于最小研发成本原则，我们做得事情主要分为精益开发流程协同支撑无人化及测试验证自动化两部分。 fish CI 主要是研发流程支撑，如需求绑定、监听变更、触发打包、触发测试等，fish guard 主要测试件调度、执行，结果通知，及后续测试件接入扩展部分。目前已接入的测试件主要有 UI 遍历、UI 识别、monkey、单元测试等。后续计划按照分层测试的原则，接入更多的测试件，如代码静态扫描、weex 自动化测试、服务端测试件等，增强测试件覆盖度，拓展自动化测试边界。关于这一部分，我们将在后面的文章中做更深入的分享。 数据度量 管理学之父彼得德鲁克说：“如果你不能度量它，你就无法改进它”，其实也是我们整个持续集成流水线的自检，我们到底做得怎么样，持续交付的能力如何，我们定义了如下指标用于后续统计。 指标主要分为响应能力、效率、质量三个维度，通过响应能力的这些指标，可以反应出打包变快了，质量反馈变快了，集成变快了，集成频率变高了；有效率的指标，反应出流水线工作的有效性，成功率越高说明流水线越稳定；最后质量，主要从代码质量和项目测试质量来度量，通过修改的文件数，模块分布可以反映出代码的拆分、依赖等情况；通过项目测试中 bug 的分布和库存，可以反映出项目质量情况，是否及时发现及时修复，是否达到发布标准等。 4、效果闲鱼从3月中旬开始试运行精益开发模式（持续交付模式）到现在，闲鱼所有的业务需求全部走精益开发模式，我们交付的速度，由一个月一个版本到两周一个版本。这离不开我们在流水线各个环节中的改进，如打包变快了，需求分支构建次数越来越多，集成频率越来越高，以及自动化测试验证及时反馈集成质量情况。此外，闲鱼在精益开发模式下质量获得了明显提升，如下图所示： 绿色分割线左半部分，是之前未切换到泳道模式前的一个版本，bug 趋势看，前面编码阶段，测试基本未介入，大量的代码批量集成后集中测试，在缺陷充分被移除后，才能交付，无法持续交付。绿色分割线右半部分，是某个业务线的缺陷趋势图，小批量的持续集成、及时测试和发现问题、及时修复，可以快速持续交付。 5、总结与规划简单总结下，我们做的事情，第一步是拉通整个交付过程，有一个稳定的交付过程，第二步保证交付的效率，即响应变快了，集成变快了，质量反馈变快了，第三步持续交付，关键词是“持续地”，频次上提出了更高的要求，集成的频率变高了，以前一个月集成一次，现在每天都能集成，从一个月一次，到 nightly build，再到随时集成。即相比以前，让开发同学“更”有信心集成一次变更并发布。 因此，我们的终极目标就是7*24随时发布，没有发布窗口限制，真正做到交付流水线自动化无人化和全自动化测试，降低持续构建成本，拓展自动化测试边界。 本文作者：琪钰阅读原文 本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

阿里妹导读：研发效能分为两块，一是用技术的更新来提升效率；二是提高整个技术生态中的协同效率，激发技术活力。阿里巴巴技术团队在此基础上要实现的终极目标是打造7*24小时灵活发布的通道，以及提供更快的业务代码迭代能力。今天，阿里巴巴高级测试开发专家傲野为你带来关于研发效能的一些思考，希望对你有启发。7*24小时发布窗口的实现其实并不简单，受限于很多因素。我简单地进行了分解。 一、系统先从最基础的开始说，当一个创业团队只有几个人，一两个系统的情况下，是可以不考虑研发效率这回事的。因为不存在系统间的依赖，系统内的依赖也完全在一个可控的范围内，本地起一个 Tomcat 或 Apache 就能开发、调试。另外再加上团队成员之间的高频交流，基本上可以实现随时随地，想发就发的要求。 当业务逐渐复杂，开发人数扩展到10几个人时。提效的第一步是理清系统内的依赖关系，并促进角色的专业化。这也是大家所熟知的MVC，通过对视图、模型、控制器的分离，对系统内的逻辑进行分层。把复杂的代码逻辑下沉到Model层，而视图层交由更专业的前端来负责。 当然，在系统内部仍然有一些扩展的空间，比如模块化，为不同的业务划分bundle等。但仍然没有突破本身的瓶颈，而且单一的系统也很难突破机器的特性。 二、架构当技术团队已经达到几十个上百人的规模，当业务已经无法通过单一的应用来进行水平扩展时。分布式的架构是解决问题的有效手段。在07年时，阿里集团就在推进SOA化，无论是淘宝还是支付宝，原来的单一应用不断被拆分出来，也在此时，承载服务化中枢的消息等中间件蓬勃发展。 这种方式实现了系统之间的解藕，激活了技术人员的生产力，同时增大了系统的弹性，实现了服务能力的低成本水平扩展。但因为复杂的调用关系，对于某一个贯穿多个应用的项目来说，无疑增加了集成的成本和质量的风险。 同时，如果对应用规模不加以规划和控制的话，会导致应用数的不断扩张，从而影响到整体的开发维护成本。 三、配置管理在5 - 10年前，阿里是有一个专门的岗位叫SCM的，负责技术团队内的代码管理，配置项管理和应用部署。特别是在服务化初期，开发人员的coding生产力被极度释放，应用数出现一个井喷，对配置管理的需求不断增强，并最终促使了配置管理的变革。 在讲配置管理前，先讲讲代码分支管理机制。这也是很多研发模式变革的起点。在此，笔者先表达自己的观点：没有对与错（先进与落后）的代码分支管理机制，只有适不适合自己团队当下以及未来发展的管理模式。 先从大的层面上来说，我们当前所讨论的都是为了解决并行开发的问题，即有多个项目或团队对于同一系列应用进行功能开发。如果仅仅是串行开发，是基本不用太考虑代码管理策略。 1、分支开发、主干发布。核心理念是使用固定的主干作为集成分支。使用分支进行开发，在合并到主干分支后生命周期终止。当然除此之外，还有紧急发布分支等。 2、分支开发、分支发布。发布成功后执行写基线操作，确保主干的及时更新和稳定。同时分支发布的方式不依赖于大集成，保持很强的灵活性。 体现在项目上的流程为： 3、其他模式：主干开发、分支分布等。由于我们并不常用，所以略过。 平台化的支持：早期配管的人肉化，也造成了代码集成和部署的效率很低。不同角色之间的协同靠人来完成。因此在那个背景下，还需要一个配套的PMO组织来保障。在这样一个历史背景下，Aone（对外版本是云效）也孕育而生，从平台化的角度来解决研发过程的协同、构建、集成和测试几个复杂的过程。为了更清楚的了解那个时期的痛点，我找了2009年左右的Aone的蓝图，可以管中窥豹（这个时期我并没有亲自经历过，只是针对于当时的前辈做了些访谈和收集了一些资料）。我猜想也正因为这条道路面向未来解决问题造就了现在的Aone平台。 四、测试当一个技术团队小，负责应用少以及业务的用户群体少时，是完全可以不用测试的。只有当业务发展到一定阶段，用户对于质量的容忍程度越来越低时，才引入专业的测试角色。其次，在软件离线交付阶段，由于软件的召回成本很高，所以对于测试是不遗余力的，但随着在线交付时代的深入，测试团队是否能够快速的实现软件质量的评测反馈，成为一个非常关键的问题。而也决定着，在打通上述各个环节后，7*24小时软件持续交付通道是否能够真正实现。 在讲之前，我们再回顾一下上个章节。Aone平台实现了开发代码、配置、应用部署的在线化，现在只剩下最后的一环：测试。从2010年以来，B2B的测试团队就希望可以把分层自动化平台跟Aone研发协作平台绑定在一起，通过系统调用的方式来实现一个测试的快速验证机制，并最终实现回归测试过程中的无人值守。 这个意义非常重大。应用的服务化后，技术的风险实际上是收敛的，大家都可以面向服务来进行开发，实现高内聚、构耦合。并且应用的发布也更加灵活了。但对于测试来说，却是极大的挑战。 1、测试的层次增加了。 2、测试的轮次变多了。每次集成，每次发布就有可能是一次完整的测试回归。 就如Aone的推进间接取替了SCM这个角色一样。研发平台的快速发展和业务7*24小时发布的诉求，也开始冲击测试在代码集成后的快速反馈能力。这是一个挑战，也是一个机会。否则，前期释放出来的所有生产力，最后全都被卡在了测试这最后一个环节，而且没有办法拆解（每拆解出来一个，测试工作量就增加一倍）。只能通过不断叠加集成的应用量来提高集成测试的效率。 经过1688测试团队几代同学的努力，现在我们在这个方面总算有了些成绩。我们已经通过分层自动化体系实现了60%以上发布测试的无人值守，并且全年拦截故障在数百个级别（含页面、UI等）。 它的实现逻辑如下： 五、文化至此，真正所谓的7*24小时业务的持续交付通道已经完全打造出来。我们再回顾一下。 1、应用内的架构分层，前端、后端、测试各应其职，通过专业化的力量激发了一轮生产力。 2、服务化的架构，让技术人员可以面向服务来进行业务的开发，实现了架构上的高内聚低耦合。进一步释放大规模技术团队的活力。 3、研发平台的搭建，提供了持续交付管道，实现了开发、测试过程的快速、准确传递。 4、依托于研发平台，实现了环境的自动化部署，应用监控，代码检查。扫除了研发过程的基建设施。让技术人员聚焦于代码的生产。 5、测试自动化验证体系，减少系统集成风险，提高集成的频率。最终实现了代码的快速上线。 本文作者： 施翔阅读原文 本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。

在如今的互联网时代，随着软件开发复杂度的不断提高，软件开发和发布管理也越来越重要。目前已经形成一套标准的流程，最重要的组成部分就是持续集成及持续交付、部署。在此，我们在京东云上以一个案例简单实践下 CI 流程。在初探前，我们有几个概念和工具需要了解下：1）、CI/CD：持续集成（Continuous Integration，CI），它属于开发人员的自动化流程。成功的 CI 意味着应用代码的新更改会定期构建、测试并合并到共享存储库中。该解决方案可以解决在一次开发中有太多应用分支，从而导致相互冲突的问题。持续交付（Continuous Delivery，CD)，通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库（如 GitHub 或容器注册表），然后由运维团队将其部署到实时生产环境中。这旨在解决开发和运维团队之间可见性及沟通较差的问题。因此，持续交付的目的就是确保尽可能减少部署新代码时所需的工作量。持续部署（Continuous Deployment，CD），这是另一种“CD”，指的是自动将开发人员的更改从存储库发布到生产环境，以供客户使用。它主要为了解决因手动流程降低应用交付速度，从而使运维团队超负荷的问题。2）、Jenkins：Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。3）、Docker：Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。4）、Git：Git（读音为/gt/)，是一个开源的分布式版本控制系统，提供代码仓库，可以有效、高速地处理从很小到非常大的项目版本管理。 Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。CI流程设计图：工作流程：开发人员提交代码到Git版本仓库；Jenkins人工/定时触发项目构建；Jenkins拉取代码、代码编码、打包镜像、推送到镜像仓库；Jenkins在Docker主机创建容器并发布主机环境规划：docker-jenkins：构建；拉取代码、代码编码、打包镜像、推送镜像到镜像仓库 116.196.85.174（公） 10.0.0.20 （内）docker-git：代码仓库 116.196.86.207（公） 10.0.0.22 （内）docker-harbor：私有镜像仓库 116.196.88.91（公） 10.0.0.21 （内）buildimage：build docker镜像 116.196.89.139（公） 10.0.0.4 （内）一、主机创建在京东云控制台创建4台云主机，地址：https://console.jdcloud.com/配置如下，购买时数量直接选择4，购买完成后再修改名称，分别为：docker-jenkins、docker-git、docker-harbor、buildimage创建修改名称后如下：二、环境配置1、云主机docker-git1.1. 修改主机名为：docker-git[root@112 ~]# hostnamectl set-hostname docker-git[root@112 ~]# hostname docker-git[root@112 ~]# logout[root@docker-git ~]#Ctrl+D退出后重新登陆生效1.2. 部署Git代码版本仓库安装：[root@docker-git ~]# yum install git -y配置git用户：[root@docker-git ~]# useradd git[root@docker-git ~]# passwd git创建库：[root@docker-git ~]# su git[git@docker-git root]$ cd[git@docker-git ~]$ mkdir tomcat-java-demo.git[git@docker-git ~]$ cd tomcat-java-demo.git/[git@docker-git tomcat-java-demo.git]$ git –bare initInitialized empty Git repository in /home/git/tomcat-java-demo.git/[git@docker-git tomcat-java-demo.git]$ lsbranches config description HEAD hooks info objects refs[git@docker-git tomcat-java-demo.git]$ 2、云主机docker-jenkins2.1. 修改主机名为：docker-jenkins[root@113 ~]# hostnamectl set-hostname docker-jenkins[root@113 ~]# hostname docker-jenkins[root@113 ~]# logout[root@docker-jenkins ~]#Ctrl+D退出后重新登陆生效2.2. jenkins环境部署部署jdk环境及maven[root@docker-jenkins tomcat-java-demo]# cd[root@docker-jenkins ]# mkdir tools[root@docker-jenkins ]# cd tools[root@docker-jenkins tools]# wget https://pocenv-hcc.oss.cn-north-1.jcloudcs.com/jdk-8u191-linux-x64.tar.gz;tar zxf jdk-8u191-linux-x64.tar.gz;mv jdk1.8.0_191/ /usr/local/;ln -s /usr/local/jdk1.8.0_191/ /usr/local/jdk;[root@docker-jenkins tools]# vim /etc/profile######## JDK #######JAVA_HOME=/usr/local/jdk1.8.0_191JAVA_BIN=/usr/local/jdk1.8.0_191/binPATH=$PATH:$JAVA_BINCLASSPATH=$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jarexport JAVA_HOME JAVA_BIN PATH CLASSPATH[root@docker-jenkins tools]# source /etc/profile[root@docker-jenkins tools]# java -versionjava version “1.8.0_191"Java(TM) SE Runtime Environment (build 1.8.0_191-b12)Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) [root@docker-jenkins tools]# wget https://pocenv-hcc.oss.cn-north-1.jcloudcs.com/apache-maven-3.5.0-bin.tar.gz;tar zxf apache-maven-3.5.0-bin.tar.gz;mv apache-maven-3.5.0 /usr/local/maven[root@docker-jenkins tools]# 安装Jenkins，下载Tomcat二进制包将war包到webapps下即可：[root@docker-jenkins tools]# wget https://pocenv-hcc.oss.cn-north-1.jcloudcs.com/jenkins.war[root@docker-jenkins tools]# wget https://pocenv-hcc.oss.cn-north-1.jcloudcs.com/apache-tomcat-8.5.38.tar.gz[root@docker-jenkins tools]# tar zxf apache-tomcat-8.5.38.tar.gz[root@docker-jenkins tools]# lsapache-maven-3.5.0-bin.tar.gz apache-tomcat-8.5.38 apache-tomcat-8.5.38.tar.gz jdk-8u191-linux-x64.tar.gz jenkins.war[root@docker-jenkins tools]# mv apache-tomcat-8.5.38 /usr/local/tomcat-jenkins[root@docker-jenkins tools]# ls /usr/local/tomcat-jenkins/webapps/docs examples host-manager manager ROOT[root@docker-jenkins tools]# rm -rf /usr/local/tomcat-jenkins/webapps/*[root@docker-jenkins tools]# mv jenkins.war /usr/local/tomcat-jenkins/webapps/ROOT.war[root@docker-jenkins tools]# ll /usr/local/tomcat-jenkins/webapps/total 75520-rw-r–r–. 1 root root 77330344 Mar 15 00:55 ROOT.war[root@docker-jenkins tools]# cd /usr/local/tomcat-jenkins/bin/[root@docker-jenkins bin]# ./startup.shUsing CATALINA_BASE: /usr/local/tomcat-jenkinsUsing CATALINA_HOME: /usr/local/tomcat-jenkinsUsing CATALINA_TMPDIR: /usr/local/tomcat-jenkins/tempUsing JRE_HOME: /usr/local/jdk1.8Using CLASSPATH: /usr/local/tomcat-jenkins/bin/bootstrap.jar:/usr/local/tomcat-jenkins/bin/tomcat-juli.jarTomcat started.[root@docker-jenkins bin]#启动后，浏览器访问（docker-jenkins）：http://Jenkins主机公网IP:8080/，按提示输入密码，登录即可。在/root/.jenkins/secrets/initialAdminPassword文件里，查看密码后填入即可按照你自己的需求安装插件设置管理员开始使用Jenkins2.3. 安装DOCKER CE安装所需包yum install -y yum-utils device-mapper-persistent-data lvm2 -y设置稳定存储库yum-config-manager –add-repo https://download.docker.com/linux/centos/docker-ce.repo -y安装DOCKER CE（这一步比较慢，耐心等会儿）yum install docker-ce docker-ce-cli containerd.io -y启动Dockersystemctl start docker3、云主机docker-harbor3.1. 修改主机名为：docker-harbor[root@c-dfjgjesgqe ~]# hostnamectl set-hostname docker-harbor[root@c-dfjgjesgqe ~]# hostname docker-harborCtrl+D退出后重新登陆生效3.2. 企业级harbor镜像仓库部署Habor是由VMWare公司开源的容器镜像仓库。事实上，Habor是在Docker Registry上进行了相应的 企业级扩展，从而获得了更加广泛的应用，这些新的企业级特性包括：管理用户界面，基于角色的访 问控制，AD/LDAP集成以及审计日志等，足以满足基本企业需求。harbor各组件介绍：| 组件 | 功能 | | :——– | :——–| | harbor-adminserver | 配置管理中心 | | harbor-db | MySQL数据库 | | harbor-jobservice | 负责镜像复制 | | harbor-log | 记录操作日志 | | harbor-ui | Web管理页面和API | | nginx | 前端代理，负责前端页面和镜像上传/下载转发 | | redis | 会话 | | registry | 镜像存储 | Harbor安装有3种方式1）在线安装：从Docker Hub下载Harbor相关镜像，因此安装软件包非常小2）离线安装：安装包包含部署的相关镜像，因此安装包比较大3）OVA安装程序：当用户具有vCenter环境时，使用此安装程序，在部署OVA后启动Harb在此我们使用第二种离线安装方式来搭建基于 https 访问的 harbor 镜像仓库。3.2.1. 下载并解压离线安装包harbor离线包下载地址：https://github.com/goharbor/h…为方便下载，我在京东云对象存储上也存了一份，可直接wget：https://pocenv-hcc.oss.cn-nor…[root@docker-harbor ~]# yum install vim wget openssl -y[root@docker-harbor ~]# wget https://pocenv-hcc.oss.cn-north-1.jcloudcs.com/harbor-offline-installer-v1.7.4.tgz[root@docker-harbor ]# tar zxf harbor-offline-installer-v1.7.4.tgz[root@docker-harbor ]# cd harbor[root@docker-harbor harbor]# lltotal 570744drwxr-xr-x 3 root root 23 Apr 1 15:05 common-rw-r–r– 1 root root 939 Mar 4 15:33 docker-compose.chartmuseum.yml-rw-r–r– 1 root root 975 Mar 4 15:33 docker-compose.clair.yml-rw-r–r– 1 root root 1434 Mar 4 15:33 docker-compose.notary.yml-rw-r–r– 1 root root 5608 Mar 4 15:33 docker-compose.yml-rw-r–r– 1 root root 8033 Mar 4 15:33 harbor.cfg-rw-r–r– 1 root root 583086399 Mar 4 15:33 harbor.v1.7.4.tar.gz-rwxr-xr-x 1 root root 5739 Mar 4 15:33 install.sh-rw-r–r– 1 root root 11347 Mar 4 15:33 LICENSE-rw-r–r– 1 root root 1263409 Mar 4 15:33 open_source_license-rwxr-xr-x 1 root root 36337 Mar 4 15:33 prepare3.2.2. 自签http证书1）获取权威认证证书[root@docker-harbor harbor]# mkdir ssl[root@docker-harbor harbor]# cd ssl[root@docker-harbor ssl]# openssl genrsa -out ca.key 4096Generating RSA private key, 4096 bit long modulus……………………………..++…………………………………………………………………………………………………………………….++e is 65537 (0x10001)[root@docker-harbor ssl]# openssl req -x509 -new -nodes -sha512 -days 3650 -subj “/C=ZH/ST=ShangHai/L=ShangHai/O=example/OU=Personal/CN=reg.marin.com” -key ca.key -out ca.crt[root@docker-harbor ssl]# lltotal 8-rw-r–r– 1 root root 2037 Apr 4 18:41 ca.crt-rw-r–r– 1 root root 3243 Apr 4 18:41 ca.key2）获取服务端证书1.Create your own Private Key:[root@docker-harbor ssl]# openssl genrsa -out reg.marin.com.key 4096Generating RSA private key, 4096 bit long modulus………………………………………++………………………………………………………………………………………………………………………………………………………………………………………………….++e is 65537 (0x10001)[root@docker-harbor ssl]# openssl req -sha512 -new -subj “/C=ZH/ST=ShangHai/L=ShangHai/O=example/OU=Personal/CN=reg.marin.com” -key reg.marin.com.key -out reg.marin.com.csr[root@docker-harbor ssl]# lltotal 16-rw-r–r– 1 root root 2037 Apr 4 18:41 ca.crt-rw-r–r– 1 root root 3243 Apr 4 18:41 ca.key-rw-r–r– 1 root root 1708 Apr 4 18:42 reg.marin.com.csr-rw-r–r– 1 root root 3243 Apr 4 18:42 reg.marin.com.key[root@docker-harbor ssl]# cat > v3.ext <<-EOF> authorityKeyIdentifier=keyid,issuer> basicConstraints=CA:FALSE> keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment> extendedKeyUsage = serverAuth> subjectAltName = @alt_names> > [alt_names]> DNS.1=reg.marin.com> DNS.2=reg.marin> DNS.3=marin> EOF[root@docker-harbor ssl]# openssl x509 -req -sha512 -days 3650 -extfile v3.ext -CA ca.crt -CAkey ca.key -CAcreateserial -in reg.marin.com.csr -out reg.marin.com.crtSignature oksubject=/C=ZH/ST=ShangHai/L=ShangHai/O=example/OU=Personal/CN=reg.marin.comGetting CA Private Key[root@docker-harbor ssl]# lltotal 28-rw-r–r– 1 root root 2037 Apr 4 18:41 ca.crt-rw-r–r– 1 root root 3243 Apr 4 18:41 ca.key-rw-r–r– 1 root root 17 Apr 4 18:44 ca.srl-rw-r–r– 1 root root 2098 Apr 4 18:44 reg.marin.com.crt-rw-r–r– 1 root root 1708 Apr 4 18:42 reg.marin.com.csr-rw-r–r– 1 root root 3243 Apr 4 18:42 reg.marin.com.key-rw-r–r– 1 root root 260 Apr 4 18:43 v3.ext3）修改harbor配置，以及为Docker配置服务端证书，key和CA。[root@docker-harbor ssl]# cd ..[root@docker-harbor harbor]# vim harbor.cfg……hostname = reg.marin.comui_url_protocol = httpsssl_cert = ./ssl/reg.marin.com.crtssl_cert_key = ./ssl/reg.marin.com.keyharbor_admin_password = 123456……密码也可以不修改，默认登录用户admin，密码Harbor12345Docker守护进程会将.crt文件解释为CA证书，将.cert文件解释为客户机证书，先将.crt文件转换一份.cert文件。[root@docker-harbor harbor]# cd ssl/[root@docker-harbor ssl]# mkdir -p /etc/docker/certs.d/reg.marin.com[root@docker-harbor ssl]# openssl x509 -inform PEM -in reg.marin.com.crt -out reg.marin.com.cert[root@docker-harbor ssl]# cp reg.marin.com.cert reg.marin.com.key ca.crt /etc/docker/certs.d/reg.marin.com/到此自签成功！3.2.3. 安装DOCKER CE安装所需包yum install -y yum-utils device-mapper-persistent-data lvm2 -y设置稳定存储库yum-config-manager –add-repo https://download.docker.com/linux/centos/docker-ce.repo -y安装DOCKER CE（这一步比较慢，耐心等会儿）yum install docker-ce docker-ce-cli containerd.io -y启动Dockersystemctl start docker通过运行hello-world 映像验证是否正确安装了Docker CE 。docker run hello-world3.2.4. 初始化及安装验证初始化安装：[root@docker-harbor ssl]# [root@docker-harbor ssl]# cd ..[root@docker-harbor harbor]# ./prepareGenerated and saved secret to file: /data/secretkeyGenerated configuration file: ./common/config/nginx/nginx.confGenerated configuration file: ./common/config/adminserver/envGenerated configuration file: ./common/config/core/envGenerated configuration file: ./common/config/registry/config.ymlGenerated configuration file: ./common/config/db/envGenerated configuration file: ./common/config/jobservice/envGenerated configuration file: ./common/config/jobservice/config.ymlGenerated configuration file: ./common/config/log/logrotate.confGenerated configuration file: ./common/config/registryctl/envGenerated configuration file: ./common/config/core/app.confGenerated certificate, key file: ./common/config/core/private_key.pem, cert file: ./common/config/registry/root.crtThe configuration files are ready, please use docker-compose to start the service.执行install.sh脚本，安装harbor仓库注意：在执行install.sh脚本之前，先检查两个问题：1）docker-compose是否安装，否则在运行install.sh时会失败，报错“✖ Need to install docker-compose(1.7.1+) by yourself first and run this script again.”2）docker服务是否正常运行，否则在运行install.sh会失败，报错“Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?”安装Compose运行此命令以下载Docker Compose的当前稳定版本：curl -L “https://github.com/docker/compose/releases/download/1.24.0/docker-compose-$(uname -s)-$(uname -m)” -o /usr/local/bin/docker-compose对二进制文件应用可执行权限：chmod +x /usr/local/bin/docker-compose执行install.sh脚本，安装harbor仓库[root@docker-harbor harbor]# ./install.sh[Step 0]: checking installation environment …Note: docker version: 18.09.4Note: docker-compose version: 1.24.0[Step 1]: loading Harbor images …bffe2a0fec66: Loading layer [==================================================>] 33.22MB/33.22MB38e174bed467: Loading layer [==================================================>] 8.964MB/8.964MB427e4936ae66: Loading layer [==================================================>] 35.77MB/35.77MB3bfd5214250a: Loading layer [==================================================>] 2.048kB/2.048kBf30df776629d: Loading layer [==================================================>] 3.072kB/3.072kBf87afad43f43: Loading layer [==================================================>] 22.8MB/22.8MB……953717aa0afc: Loading layer [==================================================>] 22.8MB/22.8MBLoaded image: goharbor/registry-photon:v2.6.2-v1.7.4[Step 2]: preparing environment …Clearing the configuration file: ./common/config/adminserver/envClearing the configuration file: ./common/config/core/envClearing the configuration file: ./common/config/core/app.confClearing the configuration file: ./common/config/core/private_key.pemClearing the configuration file: ./common/config/db/env……Generated certificate, key file: ./common/config/core/private_key.pem, cert file: ./common/config/registry/root.crtThe configuration files are ready, please use docker-compose to start the service.[Step 3]: checking existing instance of Harbor …[Step 4]: starting Harbor …Creating network “harbor_harbor” with the default driverCreating harbor-log … doneCreating redis … doneCreating registryctl … doneCreating harbor-db … doneCreating harbor-adminserver … doneCreating registry … doneCreating harbor-core … doneCreating harbor-jobservice … doneCreating harbor-portal … doneCreating nginx … done✔ —-Harbor has been installed and started successfully.—-Now you should be able to visit the admin portal at https://reg.marin.com. For more details, please visit https://github.com/goharbor/harbor .浏览器访问验证：浏览器访问要做域名解析，在本地hosts(C:WindowsSystem32driversetchosts)文件中加入：116.196.88.91 reg.marin.com访问：https://reg.marin.com，并登陆。登录后界面基本操作：新建项目test新建用户marin将用户marin设置为test项目管理员三、环境测试1、远程clone代码测试clone 云主机docker-git上的仓库tomcat-java-demo.git：[root@docker-jenkins ~]# yum install git vim wget -y[root@docker-jenkins ~]# git config –global user.email “hcc@c.com”[root@docker-jenkins ~]# git config –global user.name “hcc”[root@docker-jenkins ~]# git clone git@10.0.0.22:/home/git/tomcat-java-demo.gitCloning into ‘solo’…The authenticity of host ‘10.0.0.22 (10.0.0.22)’ can’t be established.ECDSA key fingerprint is SHA256:XNWQhGsAsqd84k/6OYV3xl1+mPGjtASsxeV1YVLZVas.ECDSA key fingerprint is MD5:b4:bd:16:2b🇩🇪e7:7c:fd:c5:dd:91:75:20:ff:3e:0a.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added ‘10.0.0.22’ (ECDSA) to the list of known hosts.git@10.0.0.22’s password⚠️ You appear to have cloned an empty repository.[root@docker-jenkins ~]# lstomcat-java-demo[root@docker-jenkins ~]# ls tomcat-java-demo/doc Dockerfile LICENSE pom.xml README.md src[root@docker-jenkins ~]# 2、拉取Github demo代码模拟生产项目，拉取github上的一个demo，并上传至本地git库[root@docker-jenkins ~]# mv tomcat-java-demo tomcat-java-demo.bak[root@docker-jenkins ~]# git clone https://github.com/dingkai163/tomcat-java-demo.gitCloning into ’tomcat-java-demo’…remote: Enumerating objects: 185, done.remote: Counting objects: 100% (185/185), done.remote: Compressing objects: 100% (165/165), done.remote: Total 185 (delta 5), reused 178 (delta 4), pack-reused 0Receiving objects: 100% (185/185), 4.50 MiB | 870.00 KiB/s, done.Resolving deltas: 100% (5/5), done.[root@docker-jenkins ~]# cd tomcat-java-demo[root@docker-jenkins tomcat-java-demo]# vim .git/config[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true[remote “origin”] url = git@10.0.0.22:/home/git/tomcat-java-demo.git # 修改为本地的git库地址 fetch = +refs/heads/:refs/remotes/origin/[branch “master”] remote = origin merge = refs/heads/master[root@docker-jenkins tomcat-java-demo]# git add .[root@docker-jenkins tomcat-java-demo]# git status# On branch masternothing to commit, working directory clean[root@docker-jenkins tomcat-java-demo]# git commit -m “all”# On branch masternothing to commit, working directory clean[root@docker-jenkins tomcat-java-demo]# git push origin mastergit@10.0.0.22’s password:Counting objects: 229, done.Compressing objects: 100% (185/185), done.Writing objects: 100% (229/229), 4.52 MiB | 0 bytes/s, done.Total 229 (delta 25), reused 229 (delta 25)To git@10.0.0.22:/home/git/tomcat-java-demo.git * [new branch] master -> master[root@docker-jenkins tomcat-java-demo]#3、自建镜像仓库上传下载用云主机buildimage上传及下载镜像修改主机名为：buildimage[root@c-dfjgjesgqe ]# hostnamectl set-hostname buildimage[root@c-dfjgjesgqe ]# hostname buildimageCtrl+D退出后重新登陆生效安装DOCKER CE安装所需包yum install -y yum-utils device-mapper-persistent-data lvm2 -y设置稳定存储库yum-config-manager –add-repo https://download.docker.com/linux/centos/docker-ce.repo -y安装DOCKER CE（这一步比较慢，耐心等会儿）yum install docker-ce docker-ce-cli containerd.io -y启动Dockersystemctl start docker首先在云主机buildimage上做本地hosts解析[root@buildimage ~]# echo “10.0.0.21 reg.marin.com” >> /etc/hosts其次编辑/etc/docker/daemon.json文件，保存退出[root@buildimage ~]# vim /etc/docker/daemon.json{“insecure-registries”:[“reg.marin.com”] }最后重启下docker，让配置生效[root@buildimage ~]# systemctl restart docker如果没有此步docker login将会报错：[root@buildimage ~]# docker login reg.marin.comUsername (admin): adminPassword: Error response from daemon: Get https://reg.marin.com/v1/users/: x509: certificate signed by unknown authority此时可以通过docker login reg.marin.com 登录harbor，输入用户名及密码：[root@buildimage ~]# docker login reg.marin.comUsername (admin): adminPassword: Login Succeeded在buildimage云主机上构建Tomcat基础镜像，并推送到harbor镜像库：[root@buildimage ~]# mkdir tomcat[root@buildimage ~]# cd tomcat[root@buildimage tomcat]# vim Dockerfile-tomcatFROM centos:7MAINTAINER hanchaochao www.jdcloud.com ENV VERSION=8.5.39 RUN yum install java-1.8.0-openjdk wget curl unzip iproute net-tools -y && \ yum clean all && \ rm -rf /var/cache/yum/RUN wget http://mirrors.shu.edu.cn/apache/tomcat/tomcat-8/v${VERSION}/bin/apache-tomcat-${VERSION}.tar.gz && \ tar zxf apache-tomcat-${VERSION}.tar.gz && \ mv apache-tomcat-${VERSION} /usr/local/tomcat && \ rm -rf apache-tomcat-${VERSION}.tar.gz /usr/local/tomcat/webapps/ && \ mkdir /usr/local/tomcat/webapps/test && \ echo “ok” > /usr/local/tomcat/webapps/test/status.html && \ sed -i ‘1a JAVA_OPTS="-Djava.security.egd=file:/dev/./urandom”’ /usr/local/tomcat/bin/catalina.sh && \ ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime ENV PATH $PATH:/usr/local/tomcat/bin EXPOSE 8080CMD [“catalina.sh”, “run”][root@harbor tomcat]# docker build -t tomcat:v1 -f Dockerfile-tomcat .[root@harbor tomcat]# docker tag tomcat:v1 reg.marin.com/test/tomcat:v1[root@docker-git-harbor tomcat]# docker login reg.marin.com[root@docker-git-harbor tomcat]# docker push reg.marin.com/test/tomcat:v1打开harbor的test仓库，查看镜像已经push成功四、CI流程测试1、Jenkins安装必要插件由于jenkins是离线安装，所有在此需要配置一下插件下载地址：系统管理–>插件管理–>Advanced（高级）修改下方地址，将https修改为http 再点提交若出现问题无法获取插件，请尝试更换地址，如：https://mirrors.tuna.tsinghua…提交后点击可选插件，此时我们可以看到很多可获得插件首先搜索并安装Pipeline插件（如果搜索不到，在已安装中查看是否已经安装完毕）pipeline 是一套运行于jenkins上的工作流框架，将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程编排与可视化。再安装SCM to job 插件，同上步骤（搜索，安装）。2、Jenkins项目创建创建jobs选择流水线类型到这里我们就开始配置Pipeline script，点击流水线语法，来自动生成我们需要的配置。如下图，我们Git方式，配置Git仓库地址，再添加认证相关。在示例步骤中下拉选择如图选项，在Repository URL中填写docker-git上的git仓库地址，因为没有添加jenkins到docker-git容器的免密码登陆，所以截图中我们可以看到连接被拒绝的一大串红色提示，我们点击添加按钮这里我们使用的是秘钥认证方式，需要在容器docker-jenkins上生成密钥，然后将jenkins上生成的公钥发送到（docker-git）git服务器上，然后将jenkins上的生成的私钥内容粘贴到下图Key中，这样jenkins就可以免交互的拉取git仓库中的代码了。[root@docker-jenkins ~]# ssh-keygenGenerating public/private rsa key pair.Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa.Your public key has been saved in /root/.ssh/id_rsa.pub.The key fingerprint is:SHA256:RQZ78bcVhLRQi8fWFPYmyvcnOqlxy980QwLsYFT/iz8 root@docker-jenkinsThe key’s randomart image is:+—[RSA 2048]—-+| .o=oooo*.|| .+.o=.* o|| .oo+.Bo.+|| .oo.+o.= || S .o.oo || .+..|| . .o.++|| +oo.E+|| ..+o..o|+—-[SHA256]—–+[root@docker-jenkins ~]# cd[root@docker-jenkins ~]# ls .ssh/id_rsa id_rsa.pub known_hosts[root@docker-jenkins ~]# ssh-copy-id git@10.0.0.22/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: “/root/.ssh/id_rsa.pub”/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed – if you are prompted now it is to install the new keysgit@10.0.0.22’s password: Number of key(s) added: 1Now try logging into the machine, with: “ssh ‘git@10.0.0.22’“and check to make sure that only the key(s) you wanted were added.[root@docker-jenkins ~]# cat .ssh/id_rsa—–BEGIN RSA PRIVATE KEY—–MIIEogIBAAKCAQEAvrI8lBov+W8v+zSGdu2EP4BPP7Ml+T5KUwc2MKX1RNMMNQxctPUf7PjhbJJvuTpPPbS1+9PAlrPhikDrug3K4+sF/Fiy+/YgoVMlEFrXiSJK1xHiErDLA39WGq+E4ssth3JfrQHV+AINGAh1/NR+Uk+YmPDAuQgA1l7jSH1PN6qTdrYt95HbklAA+Q3omAJJ4Uc80lk7ZdMcdCc0OAtHjCfbRv287qrH4U2OKSlOLljiBHBN……—–END RSA PRIVATE KEY—–[root@docker-jenkins ~]# 配置完成后，我们就可以生成Pipeline脚本了。点击下方生成流水线脚本，然后复制方框内的内容。将生成的流水线脚本复制出来，我生成的流水线脚本如下：checkout([$class: ‘GitSCM’, branches: [[name: ‘/master’]], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: ‘9baf7156-9ac6-435d-b0db-86cae51c8fe6’, url: ‘git@10.0.0.22:/home/git/tomcat-java-demo.git’]]])将生成的流水线脚本记录完成后，我们点击左上角返回继续点击配置，完成流水线项目tomcat-java-demo的配置点击流水线，我们所需要的Pipeline脚本如下，将其粘贴到script的拉取代码模块中，并修改分支/master为${branch}，其他模块内容自行编写，具体需要修改的地方和脚本如下：node { // 拉取代码 stage(‘Git Checkout’) { checkout([$class: ‘GitSCM’, branches: [[name: ‘${branch}’]], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: ‘9baf7156-9ac6-435d-b0db-86cae51c8fe6’, url: ‘git@10.0.0.22:/home/git/tomcat-java-demo.git’]]]) } // 代码编译 stage(‘Maven Build’) { sh ’’’ export JAVA_HOME=/usr/local/jdk /usr/local/maven/bin/mvn clean package -Dmaven.test.skip=true ’’’ } // 项目打包到镜像并推送到镜像仓库 stage(‘Build and Push Image’) {sh ‘‘‘REPOSITORY=reg.marin.com/test/tomcat-java-demo:${branch}cat > Dockerfile << EOFFROM reg.marin.com/test/tomcat:v1 MAINTAINER marinRUN rm -rf /usr/local/tomcat/webapps/ADD target/.war /usr/local/tomcat/webapps/ROOT.warEOFdocker build -t $REPOSITORY .docker login reg.marin.com -u admin -p 123456docker push $REPOSITORY’’’ } // 部署到Docker主机 stage(‘Deploy to Docker’) { sh ’’’ REPOSITORY=reg.marin.com/test/tomcat-java-demo:${branch} docker rm -f tomcat-java-demo |true docker pull $REPOSITORY docker container run -d –name tomcat-java-demo -p 88:8080 $REPOSITORY ’’’ }}在Pipeline脚本里面我们指定了一个branch参数，所以我们需要传递一个参数变量，这里我们选择参数化构建，默认值为master分支。然后保存配置。3、Jenkins构建任务构建前我们还需要做两个操作：添加reg.marin.com的hosts解析[root@docker-jenkins ~]# echo “10.0.0.21 reg.marin.com” >> /etc/hosts编辑/etc/docker/daemon.json文件，输入如下信息，保存退出[root@docker-jenkins ~]# vim /etc/docker/daemon.json{“insecure-registries”:[“reg.marin.com”] }最后重启下docker，让配置生效[root@docker-jenkins ~]# systemctl restart docker返回到工作台，我们开始构建任务构建开始构建完成可以通过Console Output输出查看jenkins构建流程成功构建会提示： SUCCESS通过浏览器来访问tomcat-java-demo项目：http://Jenkins主机公网IP:88/![图片上传中…]可以看到正常访问，至此在京东云上基ker+Git 的简单CI流程实践已经成功部署了。原参考地址：https://www.toutiao.com/a6中…] ...

FAQ什么是持续交付（CD）？CD是一种软件工程方法，团队在短周期内生成软件，确保软件可以随时可靠地发布。微服务、云原生架构的兴起引发了持续交付实践的必然结果。这与CI/CD有关，其中包括持续集成（CI） - 将所有开发者工作副本一天多次合并到共享主线的做法。宣布了什么？CDF（Continuous Delivery Foundation，持续交付基金会）是一个新的、中立的组织，将发展和维持一个开放的持续交付生态系统。它将提供统一的治理和与供应商中立的管理，以及对资金和运营的监督。CD基金会的第一批项目是Jenkins、Jenkins X、Spinnaker和Tekton。为什么CD社区组成基金会。为什么需要？整个行业都迫切需要围绕管道、工作流程和其他CI/CD领域合作定义行业规范，并为CI/CD工具提供基础支持。例如，Jenkins社区正在寻求一个“全方位服务”的基金会来托管Jenkins（最受欢迎的CI/CD项目之一），并构建一个增强协作的平台。还需要一个全行业的中立DevOps/CD会议。这是否代表了云原生态系统的转变？是的，市场已转向容器化和云原生技术，因此CI/CD系统、DevOps和相关工具的生态系统发生了根本性的变化。CNCF云原生互动景观展示了CI/CD领域的多样性，以及在该领域中活跃的众多项目和供应商。通过建立供应商中立的持续交付基金会，业界顶级开发者、最终用户和供应商可以将CI/CD作为方法，定义/记录最佳实践以及创建培训材料，以使全球任何软件开发团队能够交付代码更改更快、更可靠、无论它们是否为云原生。开发者为何要关心？CI/CD项目目前面临的挑战，包括工具复杂性和管道和其他CI/CD工具缺乏行业标准化，正在抑制增长和创新。由于缺乏中立的法律实体和强有力的治理，项目很难吸引新开发者和组织的宝贵支持。项目维护者和开发者花费大量时间和金钱处理安全程序和监督等方面的变通方法。这使人们不再关注新的发展和创新。拥有广泛行业支持的基金会将能够更快地定义行业规范，并为跨项目协作创造更多机会，以改善开发者的工具。谁用CD？CD广泛应用于云计算、企业IT，并且正在迅速扩展到其他顶级行业垂直领域。例如，在网络运营商与供应商并肩工作，开发CI/CD工具，使开发者能够直接与上游项目的分支合作 - 大幅缩短实施新功能的时间，并解决数月到数天的错误。使用云原生技术（如Kubernetes）时，设置CI/CD管道将加快发布生命周期。这使开发者每天可以多次发布；让团队灵活到足以快速迭代。CDF如何与渐进式交付相关？渐进式交付（Progressive delivery）是现代持续交付技术的一种形式，例如灰度发布、功能标记、A/B测试、经过验证的部署组等。渐进式交付技术和技术与持续交付密切相关。有关渐进式交付的更多信息，请阅读James Governor关于此主题的Redmonk博客：https://redmonk.com/jgovernor…这将如何影响开源软件的开发？持续交付可提高软件开发团队的速度、生产力和可持续性。CDF促进行业顶级开发者、最终用户和供应商之间的合作，以确保CD方法的软件工程充分发挥其潜力，推进开源软件开发。哪些项目将包含在CDF中？CDF正在推出四个项目：Jenkins、Jenkins X、Spinnaker和Tekton，还有更多感兴趣的项目正在筹备中。我们邀请人们关注CDF技术监督委员会（“TOC”），该委员会将在未来做出项目决策：https://github.com/cdfoundati…。我是否必须是成员才可以贡献到CDF项目？绝对不是，CDF中的开源项目或任何Linux基金会计划的技术贡献都不需要成员资格。组织作为成员加入CDF，因为它们希望在持续交付模型和最佳实践的增长和发展中扮演积极的角色，而不只是支持CDF中的开放源码项目。如果你有兴趣加入，请参阅https://cd.foundation/members…。什么是Jenkins？Jenkins是领先的开源自动化服务器，由大量不断增长的开发者、测试者、设计者和其他对持续集成、持续交付和现代软件交付实践感兴趣的人提供支持。它基于Java虚拟机（JVM），提供超过1,500个插件，可将Jenkins扩展为几乎所有技术软件交付团队使用的自动化服务器。2019年，Jenkins有超过了200,000个已知安装，使其成为部署最广泛的自动化服务器。什么是Jenkins X？Jenkins X是Kubernetes上现代云应用程序的开源CI/CD解决方案。Jenkins X提供管道自动化、内置GitOps和预览环境，以帮助团队协作并加速他们的软件交付。Jenkins X使用最好的OSS工具自动化Kubernetes的CI + CD，如Jenkins、Tekton、Prow、SkaffoldKaniko和Helm。为什么Jenkins和Jenkins X成为CDF的一员？Jenkins和Jenkins X将成为与技术兴趣相关的中立社区的一部分，并在构建开发者社区和项目治理方面获得帮助。CD基金会还将协助Jenkins和Jenkins X的营销和文档工作。这对现有Jenkins用户有何影响？将Jenkins和Jenkins X捐赠给CD基金会将促进行业内开发者、最终用户和供应商之间的更多合作。有关详细信息，请参阅此电子邮件和与Jenkins社区的对话：https://groups.google.com/for…什么是Tekton？Tekton是一组用于构建CI/CD系统的共享开源组件。它使持续交付控制平面现代化，并将软件部署的大脑转移到Kubernetes。Tekton的目标是通过供应商中立的开源基金会为CI/CD管道、工作流程和其他构建模块提供行业规范。Tekton的代码在https://github.com/tektoncd/p…。为什么Tekton成为CDF的一员？为什么Google会捐赠代码？作为CDF的创始成员，谷歌正在捐赠Tekton。正如Kubernetes通过提供一组标准的API在云中进行交互而彻底改变了应用程序开发，Google的目标是通过CD基金会为DevOps从业者提供相同的优势。CDF将提供行业规范、安全、实用和可扩展的持续交付构建块，可用于在任何地方部署代码。Tekton对knative build的影响是什么？从第1天开始，可插拔性一直是knative的核心功能。将Build与Serving分离的目标是强化这种可插拔性概念。已经对构建系统感到满意的用户可以将其与Knative Serving一起使用。Tekton将继续支持Knative生态系统作为一流的目标环境。Tekton管道将部署到Knative环境。在可预见的未来，Knative Build将继续作为Knative的一部分，专注于无服务器环境的源到容器工作流程。这两个项目将在标准和界面上保持紧密联系。什么是Spinnaker？Spinnaker是云端优先的持续交付平台，最初由Netflix创建，目前由Netflix和Google共同领导。它支持所有主要的云平台和Kubernetes，并得到各个供应商的贡献。Spinnaker通常用于大规模组织，DevOps团队通过提供“黄金路径”（golden path）应用程序部署管道来支持许多开发者。为什么Google/Netflix将Spinnaker捐赠给CDF？随着Spinnaker最近将其治理正式化，将其转移到基金会是社区自然的下一步。Spinnaker设计为持续交付平台，通常与Jenkins结合使用，因此CDF真的是项目的理想之家。Spinnaker也是一个多组件系统，在概念上与Tekton分享了许多想法 - 看到两个项目在一个基金会上聚集在一起，是将持续交付向前推进的巨大机会。这对Spinnaker用户有何影响？Spinnaker作为CDF的一员，社区将有更多机会创建更简单、更强大的端到端体验，并就CI/CD的一套通用标准进行协作。Spinnaker用户在持续交付领域拥有丰富的经验，加入CDF提供了一个与更广泛的社区分享专业知识的绝佳机会。Spinnaker用户还将受益于CDF社区中广泛的CI/CD知识，他们使用的各种工具之间的一致性，当然还有不断改进的生态系统！未来的CI/CD项目进入CDF的过程是怎样？其他项目预计将通过其即将成立的技术监督委员会（TOC）加入CDF：https://github.com/cdfoundati…，重点是将CD生态系统整合在一起，围绕可移植性和互操作性构建规范和项目。CDF的下一步是什么？接下来的步骤是启动治理结构。将成立一个理事会、技术和外联/营销委员会。我们计划在未来几个月内实现这一目标，并邀请新成员加入我们的社区。如果你有兴趣加入社区推进CD，请到https://cd.foundation/members…。CNCF的参与程度，为什么需要一个单独的基金会？首先要注意的是，CD适用于整个软件行业，而不仅仅适用于现代云原生应用程序。CNCF（Cloud Native Computing Foundation，云计算本地计算基金会）是CDF的姐妹基金会，拥有自己的治理结构和使命。每个基金会都有不同的使命，由其创始成员和技术专家定义。CNCF认为大多数与CD相关的工具超出了他们专注的云原生定义的范围，后者主要关注容器化、微服务、服务网格和编排。CDF超越云和容器，包括传统基础设施、移动、物联网、裸机等。CNCF和CDF都属于较大的Linux基金会旗下，计划在许多领域进行合作，包括同场会议。例如，CDF将于5月20日在西班牙巴塞罗那的KubeCon + CloudNativeCon Europe 2019举办持续交付峰会（CDS）活动。CDF如何支持或与DevOps领域的其他玩家合作？CDF的使命是为开发者、最终用户和供应商提供一个中立的家庭，以便在CI/CD方法上进行协作。在这方面，CDF将通过发布关注可移植性的最佳实践、培训材料和行业指南来支持DevOps从业者。有兴趣成为这个新基金会成员并制定治理方案的组织应到CDF加入的页面。开发者可以在此处注册CD基金会邮件列表：info@lists.cd.foundation。任何有兴趣加入CDF的项目都可以联系技术监督委员会（TOC）：https://github.com/cdfoundati…。KubeCon + CloudNativeCon + Open Source Summit大会日期：会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日KubeCon + CloudNativeCon + Open Source Summit赞助方案KubeCon + CloudNativeCon + Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国KubeCon + CloudNativeCon + Open Source Summit购票窗口，立即购票！CNCF邀请你加入最终用户社区 ...

新计划为Jenkins、Jenkins X、Spinnaker、Tekton项目和下一代持续交付合作提供了中立的家园加利福尼亚州半月湾 - 开源领导者峰会 - 2019年3月12日 - 通过开源实现大规模创新的非营利组织Linux基金会宣布多元化持续集成和交付（CI/CD）领域的新基础。CDF（Continuous Delivery Foundation，持续交付基金会）将作为供应商中立的家庭，为最重要的开源项目提供持续交付和规范，以加快发布管道流程。CDF将促进行业顶级开发者、最终用户和供应商之间的协作，以传播CI/CD和DevOps方法、定义/记录最佳实践、提供指导并创建培训材料，以使全球任何软件开发团队能够实施CI/CD最佳实践。由CDF托管的首批项目包括Jenkins，一个开源CI/CD系统、Jenkins X，一个跑在Kubernetes上的开源CI/CD解决方案、Spinnaker，一个开源的多云CD解决方案、以及Tekton，一个开放的CI/CD组件的源项目和规范。预计其他项目将通过其即将成立的TOC（Technical Oversight Committee，技术监督委员会）加入CDF，其重点是将CD生态系统整合在一起，以便围绕可移植性和互操作性制定规范和项目。CDF将有一个开放的治理模式，鼓励参与和技术贡献，并将为基金会CI/CD工具的长期管理和可持续性提供框架。该基金会有20多个创始成员，包括Alauda、阿里巴巴、Anchore、Armory.io、Atos、Autodesk、Capital One、CircleCI、CloudBees、DeployHub、GitLab、Google、汇丰银行、华为、IBM、JFrog、Netflix、Puppet、Rancher、Red Hat、SAP、Snyk和SumoLogic。“我们很高兴欢迎CDF（持续交付基金会）进入Linux基金会。我们正在创建一个中立的环境，以增强加速和简化软件开发和交付所需的工具和最佳实践。”Linux基金会执行董事Jim Zemlin说。“每个行业和公司都依赖软件来竞争，这就是开源和CI/CD在协作的实时软件开发团队中首选和普及的原因。”CD是一种软件工程方法，团队在短周期内生成软件，确保软件可以随时可靠地发布。随着微服务和云原生架构的使用的增加，对持续交付工具和实践的需求越来越大，为软件开发团队提供了更高的速度和生产力。“Jenkins社区很高兴由CDF（持续交付基金会）托管。在CDF下，我们希望通过更广泛的团队合作，创建一个行业范围的规范，并创建对供应商中立活动、文档、工具和支持的共享投资。”Jenkins创始人兼CloudBees首席技术官Kohsuke Kawaguchi说。“我很高兴看到CDF的形成，它开始于CI/CD领域中一些最受欢迎的最佳开源工具。”Jenkins X联合创始人兼CloudBees杰出工程师James Strachan说道。“我期待加强我们之间的合作，以帮助加速开源CI/CD领域。”“由Netflix创建，由Netflix和Google共同领导的Spinnaker是一个持续交付平台，经过数百个团队在数百万次部署中的生产测试。开发团队每天依靠Spinnaker以高速和自信的方式发布软件变更。”Netflix交付工程总监Andy Glover说道。“在一个基础上聚集的生态系统是推动持续交付技术发展的独特机会，Spinnaker社区很高兴能够成为这一发展的一部分。”Google Cloud软件工程经理兼Spinnaker指导委员会成员Steven Kim说。“持续交付是现代软件开发的关键部分，但这领域非常分散。Tekton项目通过与开源社区和其他领先供应商合作，解决CI/CD基础架构现代化这一问题。”Google云计算软件工程师Dan Lorenc表示。“建立与供应商中立的基础来创建规范，将允许快速变化的CI/CD领域充分利用容器和更广泛的云原生生态系统。出于这些原因，我们很高兴能够在CDF下托管Tekton项目，并期待与其他创始成员合作。”Cloud Native Interactive Landscape说明了CI/CD领域的多样性以及该领域中活跃的众多项目和供应商。“随着市场转向容器化和云原生技术，CI/CD系统和相关工具的生态系统发生了根本性的变化。可用CD工具的数量有所增加，并且没有关于管道和工作流程的行业规范定义，以帮助工具之间的可移植性。Capital One、CircleCI、CloudBees、谷歌、华为、IBM、JFrog、Netflix和其他CDF（持续交付基金会）创始成员，认识到需要一个中立的家，进行协作和整合来解决这个问题。CDF将建立一个项目社区，以促进围绕CI/CD的行业最佳实践和创新。”Linux基金会开发者关系副总裁兼CNCF CTO Chris Aniszczyk说。KubeCon + CloudNativeCon + Open Source Summit大会日期：会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日KubeCon + CloudNativeCon + Open Source Summit赞助方案KubeCon + CloudNativeCon + Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国KubeCon + CloudNativeCon + Open Source Summit购票窗口，立即购票！CNCF邀请你加入最终用户社区 ...

阿里妹导读：新的一年，相信很多产品技术团队把研发效能提升列为重要的目标，甚至还有团队为此专门成立了项目组。然而，到底什么是好的研发效能，却很少有人能够表达清楚。标准不清晰，又何谈提升？今天，阿里研发效能部资深技术专家何勉老师，将与大家分享他多年的思考与观点，希望对你有所启发。本文将明确定义研发效能，并提供度量的五大指标，为研发效能的提升指明目标，并衡量提升的效果。本文也是关于研发效能提升及产品交付方法系列文章的开篇，为之后介绍的产品交付方法是否有效设立了标准。效率竖井是研发效能改进的最大问题产品交付需要前后职能（如：产品、开发、测试等）和平行部门（如：前端、后端、算法等）的协作。传统方法更多关注各个职能和部门的独立改进。然而，过度局部优化，往往导致效率竖井，反而损害整体效率。什么是效率竖井呢？上图描述了传统开发方式下，产品交付面临的普遍困境——各职能和部门局部优化带来一系列问题，如：基于局部信息的工作优先级安排，造成不同部门和职能间相互等待，让需求无法顺畅流动。比如前、中、后台对工作的优先处理不一致，进度无法对齐，让已经开始的需求不能及时交付。批量式的工作移交，带来进一步等待。为了最大化单个环节的效率，各职能往往倾向于批量接受和移交工作，如批量的集成，批量的转测等。进一步造成需求在过程中的积压和等待。跨部门的问题，经常得不到及时和有效的处理。公共环境的维护，就是一个典型的问题，是影响用户需求的顺畅交付。过程中需求跨部门的有效澄清、接口对齐、问题排查是另一些常见的公共问题，它们都会造成需求无法顺畅进展。以上只是一部分问题，它们共同作用，结果是：站在各自的视角，每个部门都觉得自己繁忙且“高效”；然而，站在全局和业务的视角，系统对外的反应却非常迟缓。这就是所谓效率竖井。效率竖井：由局部优化导致，表现为：各个环节和部门繁忙而“高效”，但总体的效率和响应速度却很低。它是研发效能提升的普遍症结所在。上图的折线反映了效率竖井下，单个需求的交付过程。绿色线表示需求正在被处理，红色线则表示需求在等待中。工作量不大的需求，交付周期却很长。因为大部分时间需求都处于等待状态。各个局部一片繁忙，外部却抱怨连连，相信很多人会感同身受。“持续快速交付价值的能力”是效能改进的核心目标要改进研发效能，我们必须走出效率竖井。为此组织必须把改进的焦点从关注各个资源环节，转向关注整个系统。上图反映了效能改进的关键——从以局部资源效率为核心，转变为价值流动效率为核心的改进。资源效率指的是，各环节的资源利用率和产出情况，如：资源的忙闲程度、使用率、代码产出和测试执行速度等。流动效率指的是，用户价值在系统中的流动速度，如：用户需求从提出到交付的时长，它越短越好；或者是过程中等待时间的占比，它越小越好。用户价值的流动是串起整个系统，促进整体优化的不二选择。为了提高价值的流动效率，组织就必须关注用户价值在系统中端到端的流动过程，改进整个系统，而不仅仅是局部环节。以此为基础，效能改进的目标是：持续快速交付价值的能力。这也是对研发效能的基本定义。持续快速交付价值的能力，是研发效能的核心定义。为此我们必须把改进的焦点从局部资源效率，转向价值流动效率，以保证全局和系统的优化。研发效能的度量——五组指标回答研发效能的根本问题以上定性的定义了研发效能。管理学之父德鲁克说：“如果你不能度量它，就无法改进它”。度量帮助我们更深刻认识研发效能，设定改进方向，并衡量改进效果。产品开发过程中会产生大量的数据，但数据不是度量。好的度量的标准是：它要为回答一个根本的问题讲述完整的故事。效能度量要回答的根本问题就是：一个组织“持续快速交付价值的能力”怎么样？为回答这个问题，应该提供怎样的一个完整故事呢？基于在天猫新零售、闲鱼、优酷、阿里健康、研发中台、阿里云等部门持续实践和探索，我们发展并验证了系统的研发效能指标体系。如上图所示，它由5组指标构成，分别是：第一：持续发布能力。具体包含两个细分指标，分别是：发布频率。 团队对外响应的速度不会大于其交付频率，发布频率约束团队对外响应和价值的流动速度。它的衡量标准是单位时间内的有效发布次数。发布前置时间（也被称为变更前置时间），也就是从代码提交到功能上线花费的时间，它体现了团队发布的基本能力。如果时间开销很大，就不合适加大发版频率。第二：需求响应周期。具体包含两个细分的指标，分别是：交付周期时间。指的是从确认用户提出的需求开始，到需求上线所经历的平均时长。它反映团队（包含业务、开发、运营等职能）对客户问题或业务机会的响应速度；开发周期时间。指的是从开发团队理解需求开始，到需求可以上线所经历的平均时长。它反映技术团队的响应能力。区分交付周期和开发周期，是为了解耦并明确问题，以做出针对性的改进。其中，交付周期是最终的目标和检验标准。第三：交付吞吐率。指的是单位时间内交付需求的数量。关于这一点，常见的问题是，个数能准确反映交付效率吗？这是个问题。所以，我们更多强调单个团队的需求吞吐率的前后对比，统计意义上它足以反映趋势和问题。第四：交付过程质量。它包含两个细分的指标，分别是：开发过程中缺陷的创建和修复时间分布。我们希望缺陷能够持续和及时地被发现，并且在发现后尽快修复；缺陷库存。我们希望在整个开发过程中控制缺陷库存量，让产品始终处于接近可发布状态，奠定持续交付的基础。交付过程质量的核心是内建质量，也就是全过程和全时段的质量。而非依赖特定的阶段，如测试阶段；或特定的时段，如项目后期。内建质量是持续交付的基础，关于其具体度量方法，下文会给出详细实例。第五：对外交付质量。 它包含两个细分的指标，分别是：1)单位时间的故障（线上问题）数；2）故障平均解决时长。这两者共同决定了系统的可用性。如上图所示，这5组指标，从流动效率、资源效率和质量三个方面讲述了一个完整的故事，回答了组织持续交付价值的能力如何这个核心问题。其中，持续发布能力和需求响应周期这两组指标反映价值的流动效率；吞吐率反映资源效率；交付过程质量和对外交付质量这两组指标共同反映质量水平。一个度量指标实例：缺陷趋势图针对这些指标，云效提供了丰富的度量图表，后续云效产品团队还会进行场景化的梳理，提高其可用性。我会及时跟进，用专门的文章介绍云效的完整度量方案。在这里我先介绍一个例子——关于过程质量的度量图表。“缺陷趋势图”是云效新设计的度量图表，它反映交付过程中缺陷发现和移除的时间分布，以及缺陷的库存趋势。如上图所示，图形的横坐标是日期，横坐标上方红色竖条代表这一天发现缺陷数量；横坐标下方绿色竖条代表当天解决的缺陷数量；橙色曲线代表缺陷存量。图中左右两个部分比较了两种交付模式。左半部分，团队属于小瀑布的开发模式。“迭代”前期，团队集中设计、编码，引入缺陷，但并未即时地集成和验证。缺陷一直掩藏在系统中，直到项目后期，团队才开始集成和测试，缺陷集中爆发。小瀑布模式下，过程质量差，带来大量的返工、延期和交付质量问题。该模式下，产品的交付时间依赖于何时缺陷能被充分移除，当然不能做到持续交付，也无法快速响应外部的需求和变化。并且，这一模式通常都导致后期的赶工，埋下交付质量隐患。右半部分，团队开始向持续交付模式演进。在整个迭代过程中，团队以小粒度的需求为单位开发，持续地集成和测试它们，即时发现和解决问题。缺陷库存得到控制，系统始终处于接近可发布状态。这一模式更接近持续发布状态，团队对外的响应能力随之增强。缺陷趋势图从一个侧面反映了团队的开发和交付模式。它引导团队持续且尽早发现缺陷并及时移除它们。控制缺陷库存，让系统始终处于接近可发布状态，保障了持续交付能力和对外响应能力。缺陷趋势图是云效研发效能度量图表中的一个。后面，我会用专门的文章系统地解读这些图表的使用。效能改进的目标设定：部分团队的2-1-1愿景以上，我们介绍了研发效能度量。基于这样的度量体系，应该设定怎样的目标呢？我们在多个团队的实施过程中，逐渐沉淀出了可供参考的目标体系，它可以总结为三个数字——“2-1-1”。“2-1-1”最初来自天猫新零售，其后在闲鱼和研发中台、阿里云等团队完善和采用。什么是“2-1-1”呢？“2"指的2周的交付周期，85%以上的需求可以在2周内交付；第一个“1”指的是1周的开发周期，85%以上的需求可以在1周内开发完成；第二个“1”指的是1小时的发布前置时间 - -提交代码后可以在1小时内完成发布。[1]达成“2-1-1”的愿景并不容易。1小时的发布前置时间，需要持续交付流水线，产品架构体系和自动测试、自动部署等能力的提升。1周的开发周期，涉及更多的能力和实践，如：需求的拆分和管理，开发团队的分工协作模式，以及持续集成和持续测试实践；最困难的则是2周的交付周期，首先它要以另外两个指标为基础，同时还涉及整个组织各职能和部门的协调一致和紧密协作；“2-1-1”的目标都是关于流动效率的，你可能会问，那资源效率和质量呢？我们专注于流动效率，是因为它是组织效能改进的抓手，能够触发深层次的和系统性的改进。就像上面分析的，为达成“2-1-1”目标，团队需要技术、管理、协作等方面的全面实践升级，而这些实践的落地，必然会带来资源效率和质量的提升，并体现到相应的度量指标上。当然，“2-1-1”是源自特定的团队，并非所有团队都要使用同样的值，比如对于涉及硬件开发的团队，两周的交付周期通常过于挑战。组织应根据自己的上下文设定恰当的目标，重要的是，它要指明改进的方向。总结本文定义了研发效能，它指的是一个组织持续快速交付价值的能力，可以从流动效率、资源效率和质量三个方面来衡量。其中流动效率是改进研发效能的核心抓手，它带来系统和全局的改进。如上图所示，研发效能最终为组织效能服务，必须体现到利润、增长、客户满意度等组织效能上；同时，研发效能的提升要落实到具体技术和管理的实践中，才可能发生。定义和度量是提升研发效能的基础，相信你更关心提升研发的具体实践和方法。后续，何勉老师将综合多个团队的实践，介绍可操作的实践体系和落地方法，还请持续关注“阿里技术”公众号，我们将尽快为你送上。本文作者：何勉阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

今天我们讲讲如何利用站会，更好地实现促进团队有效协作和聚焦，促进价值顺畅流动和交付，同时及时的暴露问题和风险。站会的目标说到站会，人们最熟悉的Scrum站会，典型的形式是团队围成一圈，依次回答三个问题：昨天做了什么？今天准备什么？有什么阻碍或问题？通过站会，Scrum团队成员了解其他成员的工作，从而更好地协作，达成迭代目标。看板方法应用得当，可视化价值流实践执行到位，以上三个问题完全可以清晰地展示在看板上，所以没有必要再回答这些问题了。那站会的目标是什么呢？回到精益看板方法本身的目标：顺畅和高质量地持续交付有用的价值。相应的，看板站会要聚焦于价值的流动，而非个人工作。站会的目标是：促进团队有效协作和聚焦，促进价值顺畅流动和交付，同时通过站会同步需求进展和暴露问题及风险，把可视化价值流实践落地到位。站会的前提在建立了如下图的精益看板系统的可视化价值流，明确流转规则和限制在制品数量的三个实践之后，还需要管理价值流动和建立效能反馈闭环并持续改进。管理价值的流动具体包含管理价值流动过程，价值的输入和价值的输出，关于管理价值流动过程的一个很重要的实践就是每日看板站会。关于如何建立精益看板系统，后续会有专门的文章来详细讲解。云效看板示例：入口站会组织形式1、频次：每天（每个工作日），时长不超过15分钟，一般在早上，具体时间团队可根据实际情况调整，建议9:45或10点开始；2、三个相同：同一个团队在同一时间、同一地点在看板前进行日站会，形成固定的节奏后，会变成团队的习惯；3、协调人：团队成员站在围在看板前，由一位协调人来带领团队从右往左（⬅️）逐列走读看板；协调人可以固定，也可以轮流进行；4、电脑：为了让站会更加聚焦和高效，负责投屏和记录的同学可以带电脑，其他人不需要带电脑；站会前：需求和任务的状态已更新1、团队已按照统一优先级的规范更新需求的优先级，辅助优先级，状态、期望日期等2、开发同学按照实际情况更新需求和任务的状态（任务向需求对齐）。需求负责人负责协调把开发中的需求拆分成任务（如下图），并协调需求从开发完成，测试，直到发布完成为止；已拆分好的任务需指派到个人，任务的颗粒度在1-2天的工作量，确保每天都有看得见的进展 ，及时暴露风险和问题；任务责任人已更新好任务的状态和截止日期；如有外包-接口人合作：外包同学也需要在站会前更新状态，接口人按照流转规则进行状态流转。站会重点关注的信息站会上不需要检视每一张卡片，本着“促进价值顺畅流动和交付” 的目的，我们要重点关注影响价值流动的问题和阻碍项，如下图所示，绝大部分问题会标记橙色或红色，可以很清晰地体现在看板上。瓶颈和队列：某个环节不顺畅时，需求积压形成队列，这就是瓶颈所在，瓶颈是站会第一重点关注点，因为系统的流量往往是由瓶颈决定，只有解决了瓶颈问题，价值才能顺畅地流动。看板上的表现就是某一列的需求卡片数量特别多。关键的缺陷：缺陷会阻碍需求的流动，而且缺陷多容易出现需求积压，从而阻碍其他需求的流动。阻塞需求流动的缺陷需要及时解决，期待做到缺陷日清（缺陷发现后24小时内解决，甚至当天就解决），在Fixed状态（指缺陷已修复，待提出缺陷者验证）的缺陷需要及时验证和关闭。保持缺陷及时发现即时解决和关闭，保持存量缺陷保持低水位。站会时需要抽1-2分钟过一下整体缺陷的状况。重点关注的需求：指涉及重点商业利益或风险的重点需求，看板上会用红色的标签来凸显。阻碍和问题：指因外部（如依赖）或内部（如设计缺陷）原因无法正常流动的需求。团队需关注被阻碍的需求，跟踪和推动问题解决，及时恢复它们的流动。看板上会红色的阻碍项来标记。到期或即将到期的需求：部分需求有明确的完成时间要求，例如存在对外承诺的需求。如果它们即将到期或已经到期，就需要特别关注，以确保承诺的达成。看板上快到期的需求会用橙色凸显时间，已到期的需求会用红色凸显时间。中断：指某个步骤供给不足，价值流出现中断，如上图中，就绪（待开发）这列没有需求，此时上游队列需要尽快供给到该列。未反应在看板上的问题：走读完看板，还需要添加一个问题：“是否有为反映在看板上的问题需求沟通”。团队当然需要关注没有反映到看板上的问题，同时，团队和站会的协调人需要有意识地思考，这类问题是否可以和应该反映在看板上，以提高可视化和执行的效果。站会中：促进价值顺畅流动站会上，团队按照"站会重点关注信息6+1"从右向左检视各列，促进价值顺畅流动，同时要避免在一个问题上花费过长时间，耗时长的讨论要放在会后小范围进行。15人以内的团队，站会要能在15分钟内完成，在现实中，效果不好的站会，往往耗时会比较长。站会中讨论带来的变化，需即时更新到看板上，如有问题，也需求及时记录。下图给出了站会中应该做到和应避免的问题：还需要明确的是，站会只是团队沟通的一个场景，更多的沟通要在平时和更小范围内发生，而不是过度依赖于站会。站会后：信息透明，风险和问题跟进站会需要达成的成果：看板已处于最新的状态，反映站会讨论的结果识别阻碍需求流动的问题，并现场解决或则安排会后跟踪的Action团队成员了解项目的整体进展和状态团队成员清楚工作的优先级会后小范围讨论需求较长时间才能解决的问题。总结：站会的目标是：促进团队有效协作和聚焦，促进价值顺畅流动和交付站会要以价值交付为线索，从右向左检视需求的状态，聚焦于发现和处理价值流动中的问题不应该依赖站会检查每个人的工作，价值交付的状态和问题应该已清晰的体现在看板上，良好设计和应用的看板是高效站会的基础更多的协作应该即时发生，不应该完全依赖站会来进行团队协作一个好的站会，帮助团队了解整体的价值流动状况，促进有效的协作，并即使处理价值流动的问题，保障价值顺畅流动。附1：站会Checklist:需求和任务的状态在站会前已更新；提醒带电脑同学合上电脑，只有投屏的同学使用电脑；从右往左检视各列，按照6+1类关注点进行；开发中的需求数量是否已超过卡片数量的限制；开发中任务是否向需求对齐；需求是否按照既定的流转规则进行流转；单独快速过一下缺陷的总体状况，保持缺陷库存低水位；记录要跟踪的问题和依赖项；会后小范围讨论遗留要解决的问题；附2：站会中会碰到的问题：Q：在Scrum站会中，典型的形式是团队围成一圈，依次回答三个问题：昨天做了什么？今天准备什么？有什么阻碍或问题？为啥看板上不需要回答这三个问题了呢？A：看板方法应用得当，可视化价值流实践执行到位，以上三个问题完全可以清晰地展示在看板上，所以没有必要再回答这些问题了，同时我们需要按照需求来组织站会，关注价值流动，而不是按人来组织站会。Q：开发同学站会上讲了很多，可产品经理同学却听不懂，同时对需求的进展也不太清晰A：按照Scrum的方式，回答三个问题，开发同学往往说的是技术实现和细节，产品经理自然会听不懂。需求作为价值是产品经理的输入，看板关注的是价值流动，不是任务的完成情况，需求的状态和问题可以很清晰地在看板上体现出来，同时在开发中的需求也会拆分成各端或各模块的任务，拉通技术各角色之间的协同。这样既可以看到价值的流动，也可以看到任务的进展和对齐，产品和开发同学都可以一目了然知道目前的进展与问题。Q：为啥看板要从右到左检视各列，而不是从左到右检视呢？A：从右往左，一方面体现价值拉动的方向，另一方面是为了更好地贯彻“暂缓开始，聚焦完成”的原则，让接近完成的需求尽快的完成，而不是开始更多的需求开发。譬如测试中发现的Bug，从右到左更方便优先解决Bug。Q：站会时间到了，但还有个别同学没有到，是等他还是不等？A：团队需要共识此类事情发生的机制，避免这样的事情发生。当确实有个别成员迟到了，一般建议站会还要在固定的时间和地点进行，当然团队对于迟到可以有团队处理的办法，譬如邀请迟到的同学给大家买水果吃等等。Q：团队处于两地，甚至多地，站会如何开？A：电子看板的好处就是便于异地开发，各地成员都打开看板页面，同时用电话会议的方式接入，进行异地站会。目前Aone看板已可以做到需求卡片移动后瞬间同步。Q：两个需求都进行了近一半却都不能提测？如下图A：图中用红框圈起来的两个需求，一个是前端任务已完成，后端任务在处理中，另一个是前端任务在处理中，后端任务已完成，这总情况需要避免，团队需要聚焦其中一个需求，让其快速完成，而不是启动两个，让两个都只是完成一半或90%。附3：团队开站会的照片：Aone（云效）协作域团队信息平台诉讼团队阿里云飞天一部工业大脑CEM客户运营平台的物理看板的站会站会上很多人都带电脑，效率就会相对低，不建议出现这种情况。作者介绍：洪永潮（花名：舍卫），现就职于阿里巴巴研发效能事业部阿拉丁团队，先后负责手猫、手淘、天猫新零售等阿里内部多个部门的效能提升，曾担任MPD、GIAC、RSG、 DOIS等大会的讲师。关于云效：云效，一站式企业协同研发云，源于阿里巴巴多年先进的管理理念和工程实践，提供从“需求->开发->测试->发布->运维->运营”端到端的协同服务和研发工具支撑。支持公有云、专有云和混合云的协同研发，助力企业产品快速创新迭代和研发效能升级。云效产品：项目协作 https://www.aliyun.com/product/yunxiao-project代码托管 https://promotion.aliyun.com/ntms/act/code.htmlMaven公共仓库 https://m.aliyun.com/markets/aliyun/ali-repo制品仓库 https://m.aliyun.com/markets/aliyun/repo-manage持续交付 https://www.aliyun.com/product/yunxiao-cd测试平台 https://www.aliyun.com/product/yunxiao-testing本文作者：云效鼓励师阅读原文本文为云栖社区原创内容，未经允许不得转载。