基于AWS的跨区域持续交付实践

luna
作者：薛倩

名词解释

AWS：是亚马逊的一个云服务平台，每年会提供很多服务，比如帮我们托管，简单的存储等。跨区域也是基于AWS的，它所谓的云服务其实是自己的一些服务，建立在不同的区域。跨区域是基于自己的服务和应用，我们会部署AWS不同的区域，国内国外都有。

E2E 测试:可以把它理解成一个UI层面的测试，两个END, 一个是前端，另一个是数据库，大的完整的功能性的测试，因为你可能有一些不同的策略之间的集成测试。

什么是持续交付

从一个代码的周期来看，我们默认是一个敏捷团队参与，在本地开发出代码之后，会把它上传PUSH到远端的代码库，通过持续交付流水线，帮我们部署成一个线上产品。具体看一下持续交付会干哪些事，我们把它分为两个大的层面。首先是本地，开发人员开发出代码之后，可能在本地跑完本地的测试，本地构成完成之后会把它上传到远端的代码仓库。代码仓库会自动触发持续集成服务器，持续集成服务器帮我们打包，然后会上传到定义好的工具或者是定义好的存储仓库里，之后会帮我们做一些测试，这个流程最终的状态如果是OK的就会把生成好的包安装到不同的环境里，如果说这个环节里有任何一个是错误的它就会返回一个失败的框给开发人员，就不会走下面部署的流程。如果是成功的，我们一般会把环境分为三个，测试，staging和production。

为什么要应用持续交付？

总的来说就是快速迭代，帮助我们更好的快速迭代。共四个方面：

1. 更短的交付周期，每次提交是自动去触发，如果测试和打包都跑过之后，它会帮助我们自动的部署到开发以及Staging的环境，这时就会促使各个环境部署的频率越来越频繁，如果没有这样的自动化流程你需要手动，就会很繁忙。
2. 更好的质量保障，刚才大家也说了，在代码审查、单元测试、功能测试都加在服务器里，它在对生产方面是很好的保证。
3. 更高的交付价值，Staging环境其实是可以在上线之前去快速给客户反馈的，有了这个就有持续交付的闭环，从你的客户那没有上线之前快速的得到反馈，这个反馈可能会影响你对项目的计划以及需求做进一步的调整，我们通过一些工具在用户那得到需求，然后我们可以去做变更。
4. 另一个是更高效的团队，大家工作在一起，有了这样的自动化流程，大家可以密切协作，避免高成本的沟通。
   

持续交付实践

项目背景

基于AWS的跨区域持续交付是怎么做的？
简单介绍一下项目的背景，我们是一个服务于房地产的公司，目前支持3个国家，分别是澳大利亚、中国和美国，现有数据2.7M+，我们的数据是来自于不同的源，我们需要把这个数据通过处理之后转成知识，是完全从研究的数据到展示，是一个端到端的模式。

再看一下我们用了AWS里的哪些服务，刚才说了我们是支持三个国家，一开始其实我们只支持澳大利亚这一个国家。这张图我们不一一过，之后随着我们要引入别的国家，只支持澳大利亚之后又有了中国和美国，所以我们有了SQS和SNS, 为什么有这么多，是因为我们的数据更多，必须选择高可用的服务来支持正常的交付。

我们面临的挑战是什么？

如何基于AWS不同区域进行部署产品，如果并行的部署我们的产品。

如何实践持续交付？

再看一下这个流程图，之前的流程图大家都记得，帮我们打包的流程几乎都一样，主要是步数不一样。刚才看到的每个环节都只有一个，现在除了测试环境Staging有三个，我们这里是配成并行的自行触发生产环境，之后会加一个手动的触发，它会并行的同时部署到production的环境。

我们接着往下看，我们是怎么实现的。第一个是基础设施即代码，第二个是流水线即代码。

基础设施即代码，通过代码来定义计算机和网络基础设施的方法，可以应用于任何软件系统中，这样的代码的好处是可审查、可重用而且符合测试管理，完全遵从持续交付的原则。

基础设施即代码想希望达到的标准是什么。一个是标准化，利用代码帮我们定义环境，所有环境的配置都是标准化的，由代码控制、开发、测试和生产。二是自动化，用工具来自动化准备环境，包括机器的生成、机器的配置以及部署。三是可视化，用监控来可视化环境信息，环境状态可视，环境变更可视，环境变更可追溯。

我们用到了两个工具，一个是CloudFormation 另一个是ANSIBLE, 这两个合起来就可以实现我们现在所说的基础设施即代码。

我们展开一下看是什么做的，这个可能看不清楚，这是我从网上粘过来的代码，不用去看每个细节，你要用到AWS的每个服务都有模版帮你定义好，但如果你有自己要定义的就可以把它输成变量传过去，具体怎么实现大家可以看文档。

CloudFormation，刚才我说到有几个不同的环境，变量是怎么传的，首先是CloudFormation里放的是所有要应用的AWS的模版，自定义的变量可以传在这里，你要部署的包是哪一个，可以自定义的东西都可以放在这，之后里面会有不同环境的权限，我们会打到里面，所以在CI上其实跑的很远，变量仅限于不同环境。

流水线即代码，我们是基于Jenkins2.0之后可以使用DSL语言进行行行步骤定义，大家可以具体的看脚本，帮你配置具体的并行流程是什么。

举个例子，这是刚才说的除了部署之后还需要建设的，帮我们去跑测试和打包的流程，在这里测试的步骤是什么，构建的是什么，push是什么，我们一般会把build和deploy分开。Deploy到不同的环境和配置，用代码的方式去定义流水线。

蓝绿部署刚才说到不同的方式，具体每一个环境到底是怎么做的，不是说一个Test的deploy就上了，其实我们用的是蓝绿部署的概念，我们设想对于一个环境来说，已经有了正在跑的代码在上面，其实我们用到的是AWS，它会帮你去管理所有和它相关的，比如在上面跑的状态等，当我们触发了这一deploy到Test之后，会帮我们再新建一个新的配置，到这在线上跑的还是旧的，之后我们会有SWICH的操作，帮我们切换到新的，切完之后相当于所有的流量都导入到新的里面，旧的没有用了就会删除，每一个Deploy的操作就包括3个流程。

SWICH之前什么都没有做，我们有一些配置是不一样的，不同的环境配置不一样，大家有没有开关的概念，这个开关可以帮你控制这部分的代码要不要正常运行，我们会用E2E Test来帮你管理不知道现在要不要上线的功能，针对这个环境，E2E的配置可能都不一样，我们在Deploy和SWICH之间有一个是E2E的测试，有一段时间有一个场景是同样的代码上了production功能没有，QA开发各个角色的人员其实上线之后都会点一点，看功能是不是全面的，但并不可能面面俱到，可能会有一些小的点没有覆盖到，会发现有些功能线上没有，这时特别伤心，我们就会加一个对于主要功能的测试，把它从正常的build的判断里提出来，我们把它提成一个单独的放在Deploy之间，即我们部署新的之后，基于这个新的，通过它内部可以对主要功能进行测试，这样主要功能就是OK的，没有被不小心关掉，没有受影响，最后再Clean. （要做端对端的测试之前，其实已经SWICH了一次。）
这个图是画错了，画反了。