从源码到上线

事情可不简单

什么叫程序？或者说，什么叫软件？这里面好像有歧义。有时候指的是源代码，有时候指的是安装包或者安装光盘，比如“我下载了一个软件” 。有时指的是已经安装好随时可以运行的程序，比如“手机上新装了一个应用” 。还有的时候指的是正在运行中的，正在提供服务的程序，比如一个网站。

这些不同的含义反映了一件事：单纯的源代码，还不能提供服务，不能为用户带来价值。只有源代码被构建打包，并且被部署运行起来，才能为用户带来价值。

那么，如何才能部署运行起来，为用户提供服务呢？这很麻烦吗？——是的，这很麻烦。

想象一下，如果你是一个初创企业的CTO。天上忽然掉馅儿饼，掉下来五个Git库，源代码已经写好，而且一点儿毛病都没有。每个Git库能编译成一个war包。你需要把每个war包部署到100台服务器上，总共需要500台服务器。另外，随着用户的使用，会不断追加新功能，产生新版本，需要更新服务器上的软件版本。

假定你不是在阿里巴巴，假定也没有阿里云，假定你只是有很多钱可以雇到合适的人，你想想一共有多少事情要做？

先要买或者租机房，再买服务器，风火水电都要搞稳妥。更要接好网络，每台机器要装好操作系统的合适版本。不止是操作系统，还有相关基础软件、路由、数据库、监控系统、日志收集系统以及中间件等都是必须的。哦，域名还忘了申请了……

这些搞定之后，才能安装那些war包。这么多台，肯定不能一台一台操作，累死了，得有个批量操作的方法。可这方法怎么弄呢？另外，考虑到将来要更新软件版本，所以这还不是一次能搞定的事情，那更是得批量操作了。更新版本的时候，还有个麻烦事，不能一下子都停机啊，那不就要出事故了。所以得分批来。比如，先更新20%的机器，再更新20%，如此一共五批弄完。

往细节看，其中更新某一台机器，其实都是个挺复杂的过程。首先下载新的war包到这台机器，然后开始替换过程。先得把流量切走，切流量前，还得先把监控报警关上。流量切走了，就可以停止当前war包的运行。然后用新的war包代替旧的war包，启动试试看。如果通过了一些基本的自动检测，说明新war包大体上能运行，于是就开始切流量回来，最后把监控报警恢复。

忒麻烦！！

还好有工具帮忙

怎么办？——用趁手的工具啊！正是为了提高大家的工作效率，让大家能够集中精力在具体业务本身的研发上，阿里巴巴集团多年以来建设了一整套基础设施。

在交付层和运维层，都有大量的基础设施。但这些，大家可能感受不深。对于一个应用来讲，它最关心的事情，基本都是通过Aone暴露出来的。Aone也就是最上层研发层的主要工具。

注：本文提及的阿里内部产品叫Aone，Aone于2017年正式对外开放，更名为云效。

回到前面讨论的场景，把完美的源代码发布上线这个过程，那么大体步骤应该是：

第一步，把运行环境初始化好。这一步目前同学们基本可以在Aone上一站式完成了，就是在Aone上注册一个新应用，然后根据向导指引，把上线任务一项一项配下来。当然还有些内容比如数据库还需要访问其他系统申请配置，将来我们努力做成一站式配置好。

第二步，根据源码构建出压缩包（基本就是把war包压缩一下），然后把压缩包部署到各目标服务器上。这一步，可以在Aone上一键完成。将来更新版本也一样。点一下按钮，所有事情都做完。这就是用Aone的好处。

阿里巴巴相关术语

为了使用Aone，我们得了解一些Aone的关键概念。其实是在阿里巴巴开发时，大家一开始约定俗成的概念，后来固化在Aone上。我们一个一个来看：

应用：Git库里装的是源代码，这是程序的一种形态。那么运行中的程序叫什么呢？在阿里巴巴，我们管它叫“应用”。一般来说，一个Git库，构建生成一个包，产生一个应用，在若干台服务器/虚拟机/容器中运行，在测试、线上环境中运行。一般应用跟Git库是一比一的关系，不过也有各种特殊情况，比如一个Git库里有多个应用。所以，我们确实需要应用这个概念。另外，应用不仅包括了应用主包（通常是war包打成tgz包），也包括了运行所需环境的配置，比如tomcat版本等。

二方包：三方包，指的是来自阿里巴巴外部的，开源或商业的包，比如jar包、rpm包等。而二方包，则是指来自阿里巴巴内部的，通常是其他团队的包。也就是说，一个团队研发出这个二方包，公布出来，供各团队使用。当然，也可能就是供团队自己使用。反正，只要是来自阿里内部的，上传到Nexus或Yum这样的包的仓库的，就都算二方包。

产品/产品线/产品树：应用是从部署运维的角度看运行中的程序。产品是从使用者的角度看运行中的程序。通常产品由一到多个应用组成。产品进而构成产品线，这样一级一级地上去，形成了一棵树，叫产品树。产品树的根节点，就是阿里巴巴。产品树的第一级展开，是各个BU。

变更：在外面的世界，现在变更通常是指线上运行环境的变化，比如更新了软件版本，比如扩容、缩容等运维操作。在阿里巴巴，变更也有这个含义。但是在阿里巴巴，变更还有一个含义，软件研发过程中的含义。通常我们把一条feature分支就对应到一个变更。于是也常管这条feature分支叫变更分支。从这个角度看集成，就是把若干变更攒到一起，通过各种质量检测后，部署上线。

发布：发布，release，这个词常常是指软件版本公布出来供使用。但在阿里巴巴，这个词不仅对应于部署到线上环境，即使是部署到测试环境，也叫发布。换句话说，发布基本上就是部署的代名词。比如每个变更觉得自己OK了，就点一下变更详情页面上的“提交待发布”这个钮，标记一下。然后，在集成测试环境（也就是日常环境）对应的流程阶段的详情页面，就能看见这个变更。再选中它，然后点击“提交发布”这个钮，就与其他变更分支一起合并到发布分支，并部署到测试环境啦。

技术发展趋势

发布部署方面，在阿里巴巴，时下最重要的变革当然是Docker化。

那么这一波浪潮之后，下一波浪潮会是什么呢？有可能是Serverless架构。这方面的文章也很多，大家可以翻翻看。

提高质量的多种方法

刚才我们给的是一个天上掉馅儿饼的例子，忽然间得到了完美的源代码，然后考虑构建并部署上线。现实世界中哪儿有这样的好事儿啊。代码里面肯定有bug。那么，怎么能够有效率地把问题找出来，继而修复好？具体有哪些方法？

按四个象限梳理

为方便梳理，我们划一个横轴，一个纵轴，然后按照得到的四个象限，梳理各种质量保证方法。这里所说的横轴，在最左边，是源代码。在最右边，是运行中的程序。这里所说的纵轴，在最上边，是自动化，在最下边，是人工。

先看左半部分。左下角，人工的对源代码的检测。这主要对应的是代码评审。我们在代码服务这门课上介绍的。此外，安全评审有时也有人工介入。

左上角，自动对源代码的检测。代码规约的自动检查工具，就落在这里。事实上，还有不少工具也落在这里，论品牌，有Sonar、PMD等。论方法，有圈复杂度等。所有这些自动检测，被称之为Staticprogram analysis 或 Static code analysis，静态程序分析/静态代码分析。

这方面，在阿里巴巴有工具支持，对应的是Aone的实验室这个功能。可以通过实验室，接入各种静态程序分析工具和方法。实验室的前身是CISE。现在CISE也仍然是实验室背后的引擎。所以有时候听别人说CISE的时候，你就知道其实指的就是实验室啦。

再来看右半部分。右上角，是自动的对运行中的程序的检测。这也就是常说的自动测试啦。在阿里巴巴，也是主要由Aone的实验室来向大家提供相应服务。这包括单元测试/集成测试；接口测试/Web UI测试；功能测试/性能测试，等等。

右下角，是人工测试。虽说是人工测试，工具也同样可以提供支持，主要是管理测试用例。相应的工具是Aone中的测试用例管理。

测试环境隔离技术

不论是自动测试还是人工测试，只要是需要先把应用部署到测试环境，那就跟测试环境的管理有关系了。测试环境的管理，我们专门讲一讲测试环境隔离技术。

想象一下，你开发了一个feature，也就是一个变更。为了让它比较靠谱再送去集成，你需要对它进行测试。单元测试当然好，但这是不够的。需要尽可能模拟真实环境进行测试。那么问题来了，如何尽可能模拟真实环境？比如，为每个淘系的工程师另搭一个淘宝测试用？这费用咱真花不起……

怎么解决这个问题？阿里巴巴用了一个聪明的方法，测试环境隔离。让大家共享一个测试环境，但又仿佛每个人都是独占它的，互相不干扰。

具体说来，假定搭起一套测试环境，需要1000台机器，分别运行应用ABCDE……。这个环境我们称作日常测试环境。每个应用的版本，我们姑且称之为A0、B0、C0、D0、E0……

现在假定甲这名同学在开发A这个应用的一个变更，在开发过程中，现在产生的应用版本是A1。于是把A1部署到单独一台机器上，并用一些神奇的技术（通过中间件等）与刚才说的日常测试环境连通。于是，在甲这名同学看来，他所面对的系统是A1、B0、C0、D0、E0…… 而且仿佛他独占了这个系统。

类似地，如果乙这名同学为了一个feature，在开发A和B分别拉出变更分支，产生A2、B2。那么A2、B2将分别被部署到单独的机器上，然后它们一起与日常测试环境连通。于是，在乙这名同学看来，他所面对的系统是A2、B2、C0、D0、E0…… 从乙的角度看，他仿佛独占了整个测试系统。甲和乙在测试时，不会互相干扰。

有了这样的解决方案，就同时达到了两个目标：尽量模拟真实的环境；用不高的代价。

关于测试环境隔离技术，这里只是简单介绍下原理。

阿里巴巴相关术语

项目环境：就是前面说的，测试一个feature所需的测试环境。可能对应一个应用上的一个变更，也有可能对应多个应用。项目环境使用了上面讲的测试环境隔离技术，背后接的一整套测试环境，是日常环境。

日常环境：就是集成测试环境。把各个变更攒在一起，然后部署到这里，看是不是能work。

预发环境：这个环境比日常环境更接近真实环境。事实上，从网络隔离的角度，它不是在测试网，而是在生产网。它所连接的数据库，也通常就是线上运行使用的数据库。一般来说，是先在日常环境测试，通过了再到预发环境测一下。

正式环境：正式环境就是生产运行的真实环境，向广大用户提供服务。

流水线

所谓流水线，通俗地讲就是把不同的工作按一定顺序串起来。为什么要串起来呢？

首先，有些工作天生就是有先后顺序的。如果想部署，总得先构建吧。所以构建-部署，就是天然的工作顺序。如果每次都是先点个按钮做构建，等构建结束后再点个按钮做部署，好像有点儿笨，不如点一个按钮，把这两件事按顺序都做了。

其次，为保证质量，我们想往流程里面加规则和卡点。比如，必须通过代码评审和安全评审，才允许合并代码。这些质量保证性的工作，还有可能有不同的顺序和频率。典型的单元测试和静态程序分析应该早做，频繁地做。而整个链路的测试，比较费劲，频率可以相对低些。因此，这些工作也是流水线中的环节，并且可能以不同频率执行。不同频率这个事儿，就是持续交付这个流行词儿中所说的不同stage(阶段)不同频率。

Aone提供了把不同的工作串接的能力，也就是流水线的能力。在分支模式下，每个环境，比如日常、预发、正式，分别对应一条流水线。在Git Flow和自由模式下，你甚至可以把所有工作内容，从代码提交到最后正式发布，做到一个流水线里。看着代码过一道道“关口”，然后发布上线，还是很爽的。

结语

以上，概要地介绍了从源代码到上线的基本的构建部署过程，讲解了各种质量保证方法及其工具支持，讲解了流水线把流程作业连接起来自动运转。这些能力合在一起，就实现了对持续交付的一整套工具支持方案。当然，如果你问DevOps的工具支持方案，我也会说，以上几部分，构成了DevOps的工具支持方案…… 名字是次要的，关键是帮上广大研发同学的忙，高效且稳妥的开发和发布。

这节课只是概要介绍。有需要的童鞋可以使用Aone的对外版本云效，体验一位阿里技术人工作的一天。