76 lines
8.3 KiB
Markdown
76 lines
8.3 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
153 施翔：如何打造7 24高效交付通道（下）
|
||
你好，我是阿里巴巴高级技术专家施翔，研发效能的提升是技术团队都需要关注的话题，而打造一个7*24小时的交付通道就是一个非常有力的着眼点。
|
||
|
||
在整个交付通道中，架构、配置、测试、发布是提升效能的几个关键点，上一篇文章分享了我们在架构、配置这两个环节的做法，今天将继续分享我们在测试、发布等环节的实践。
|
||
|
||
测试—高频率低成本
|
||
|
||
在架构、配管以及打通的基础上，接下去就到了测试环节。其实，当一个技术团队比较小的时候，测试环节并不是那么必要，当业务发展到一定规模、用户对于质量的容忍度越来越低的时候，才需要去引入专业的测试环节。
|
||
|
||
另外，在过去，传统软件是离线交付的模式，软件的交付程度非常高，所以对于测试来说，它是不惜余力的，哪怕要花费更多的时间、更多的精力，也要把测试做好。但现在在互联网模式下，更多的软件是在线交付的模式，测试团队的角色也发生了一些变化。以前，他可能是一个守门员，守在研发环节的最后一道关口，把控软件的质量，而现在，他需要考虑怎样才能尽快对软件质量进行反馈，这是非常关键的一点。这一点也决定了测试成为了整个研发交付环节中非常重要的一个环节。
|
||
|
||
测试包括单元测试、功能测试、系统测试、集成测试、回归测试等不同的方法，今天我想重点分享的是集成测试。对测试来说，发布越频繁，对集成测试的要求就越高，越需要可靠低成本的集成测试方案。
|
||
|
||
上一篇文章中，我们提到，代码分支管理有两种不同的策略，一种是分支开发、主干发布，一种是分支开发、分支发布，它们其实就对应着不同的集成策略。
|
||
|
||
第一种策略，通过项目过程中不断的merge，不断减少分支和主干的冲突，来提高项目间的集成效率。在这个过程中，也可以用项目过程中的功能测试来覆盖小集成的需求。
|
||
|
||
第二种策略，用空间换时间，多个项目一次性集成，提高单次集成效率。在这种策略下，必然会有多个项目在集成区域等待，甚至可能有的项目提前一天就等在集成区了。除了能提高单次集成的效率外，这种模式还适用于比较复杂的系统，例如阿里的一些业务系统，需要从端到端的验证的时候，就需要这种集成方式，来确保它们从端到端的同步。
|
||
|
||
第三种策略，无人值守集成测试，回归本质，通过测试技术手段来解决多项目集成过程中的频繁验证的问题，这也是更能保证测试灵活性的方式。
|
||
|
||
同时，作为技术人，我们会希望通过无人值守自动化，来解决合并过程、集成过程中的一些质量效率问题，也只有这个问题解决了，我们才能一步一步往下打通到测试环节，不再让人的效率问题影响到整个交付通道的效率。
|
||
|
||
发布——更灵活，可感知
|
||
|
||
在互联网行业，相信不少技术团队都遇到过这样的情况，就是无论你开发上线速度有多快，业务同学总希望你们更快，甚至可能会出现一些变态的业务需求，比如要求一天开发，一天上线，那怎么办呢？其实我们是可以在发布上下功夫的。
|
||
|
||
举个例子，阿里现在有很多发布模式，比如正式发布、Beta发布、预发布、分批发布、灰度发布、隔离发布等等。我们也希望，如果有一天，业务真的紧急到了这样的程度，需要第一时间上线的时候，我们可以通过这些灵活的发布方式来解决它的效率问题。
|
||
|
||
阿里CBU技术部的一些实践
|
||
|
||
说了那么多理论，接下来我将分享我们CBU技术部在打造这个7*24小时交付通道中的一些实践。
|
||
|
||
先来看分支管理和发布策略，如下图所示，这是我们整个的发布通道，采用的是分支开发，分支发布的策略。对于整个发布通道，我们定义了四个流程状态。
|
||
|
||
|
||
其中，第一个是正常的从预发到正式发布的流程，中间有开发、构建、预发、正式发布、提交、写基线到结束的整个从预发到发布的过程。而第四个就是相对快速一些的发布通道，从开发、构建到正式发布，相较于第一个流程，它省去了中间一些预发的环节。
|
||
|
||
再来看无人值守自动化能力的建设。我们讲协同的时候，通常指两方面，一个是人与人之间的交流、协同，另一个是系统与系统之间的协同，而我们做的就是第二种，强调系统之间的协同。
|
||
|
||
过去常说，我们是面向过程来开发、面向对象来开发、面向服务来开发，未来，我们应该是面向平台来开发。以无人值守自动化系统为例，如图中所示，上面是整个Aone研发平台，开发者可以在这个平台上提交代码，进行预发代码集成、代码静态扫描，乃至预发等等操作。
|
||
|
||
|
||
而当系统到了预发的状态后，就可以通过一些操作促发下面一层的自动化体系，并通过这个分层的自动化系统及时进行反馈。我们对自动化的要求是，任何一次集成、任何一次发布，都需要在30分钟内跑完所有的用例，并给到Aone平台分块，通过彼此系统间的交互解决效率问题。
|
||
|
||
我这里有一些自动执行的数据，截至目前为止，我们整个部门中50%左右的发布是完全由自动化实现的，基本不需要人力参与。另外，去年一年，通过这个自动化系统，我们线上拦截了30多个问题数据，预发拦截了60多个问题数据，日常拦截了100多个问题数据。同时，构建次数达29000多次，活跃功能测试件数量达1100多个，运行的case数达80000多个。
|
||
|
||
之前提到，整个交付通道打通以后，我们从拉分支到正式发布的平均周期缩短到了5.29天，目前整个部门的应用数有1000多个，开发人员有350多人，一年下来集成自动化大概是29000多次，发布大概是15000多次。
|
||
|
||
这些是非常优秀的数据，但可能对于老板来说，光有结果不行，还需要有过程，为此，我们专门打造了一个部门提效中心。我们做任何工具、任何平台，都要考虑它们到底能不能产生价值，那怎么衡量和定义这些工具平台的价值呢？
|
||
|
||
我们想了一个最简单的方法，比如自动化以前，通过人肉去集成的话，可能需要一个小时，现在自动化之后，通过工具或平台去执行集成的话，可能只需要10分钟，那么对于这个工具或平台而言，就是执行一次，提效50分钟。我们通过这样的方式去衡量整个提效过程的成果。
|
||
|
||
|
||
可以看到，过去一年，我们大概提升了2177个人日，基本占了部门总人日的5%。
|
||
|
||
结语
|
||
|
||
回顾一下，我们通过架构的升级，极大的激发了开发同学Coding的活力与能力；通过平台化、系统化解决了配置、测试环境等问题；通过无人值守的自动化集成测试解决了集成质量与效率的问题；通过灵活可感知的方式解决了随时随地发布代码的问题。
|
||
|
||
这样一条路走下来，大家会发现，其实整个交付通道已经打通了，也就意味着，除去开发时间，任何一款代码都可以在7*24小时内的任何一个时间点快速上线，解决了之前可能出现的排队发布时间长、集成测试效率低等等一系列问题，这就是我们这么看重交付通道打通的原因。
|
||
|
||
感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友~
|
||
|
||
作者简介
|
||
|
||
施翔，TGO鲲鹏会会员，现就职于阿里巴巴CBU技术部，担任高级专家职务，质量技术、稳定性和DevOps团队负责人。曾就职于中兴、支付宝等公司，在系统高可用、测试工具研发、研发效率提升等方面有着丰富的经验。
|
||
|
||
|
||
|
||
|