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

名词解释

AWS： Amazon Web Services ( 是一个安全的云服务平台，提供计算能力、存储选项、联网和数据库等实用服务来托管我们的基础设施服务。标题中的跨区域是指基于AWS的不同区域。

E2E测试： end-to-end测试可以理解为是UI层面的测试。连个END，一个是用户可以访问的页面，另一个是最底部的数据库。对于E2E测试来说就是从用户的角度出发，除了前端以外其余都是黑盒，用来测试完整的功能是否正确。

什么是持续交付

从一个代码的周期来看，我们默认是一个敏捷团队参与，在本地开发完成代码实现之后，会把它提交到远端的代码库。通过持续交付流水线，帮我们部署成一个线上产品。

持续交付流水线是一个很重要的连通远端代码库到线上产品的过程。可以将持续交付流水线分为两大部分。一是构建，另一个是部署。

构建流程是开发人员在本地跑完测试之后将代码上传到远端的代码仓库，代码仓库会自动发送信号到持续集成服务器；

持续集成服务器将代码以及相关依赖构建打包，然后会上传到指定的工具或存储仓库里。然后开始运行测试，包括单元测试以及一些集成测试或者其他。

这个流程最终的状态如果是通过的就会把生成好的包安装到不同的环境里，如果上述流程有任何错误就会返回失败的信号，就不会出发部署的流程。如果是成功的，我们会将部署在三个环境，分别是dev，staging和production。

为什么要做持续交付，可以从四个方面来看：

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

1. 更短的交付周期，每次提交是自动去触发。

   如果测试和打包都跑过之后，它会帮助我们自动的部署到开发以及Staging的环境，这时就会促使各个环境部署的频率越来越频繁，如果没有这样的自动化流程你需要手动，就会很繁忙。

2. 更好的质量保障，在代码审查、单元测试、功能测试等都集成到了CI中，在质量方面有很好的保证。

3. 更高的交付价值，Staging环境其实是可以在上线之前去快速给客户反馈的，有了这个就有持续交付的闭环，从你的客户那没有上线之前快速的得到反馈，这个反馈可能会影响你对项目的计划以及需求做进一步的调整，我们通过一些工具在用户那得到需求，然后我们可以去做变更。

4. 另一个是更高效的团队，大家工作在一起，有了这样的自动化流程，大家可以密切协作，避免高成本的沟通。

持续交付实践

项目背景

基于AWS的跨区域持续交付是怎么做的？ 简单介绍一下项目的背景，我们是服务于一家海外房地公司，目前支持澳大利亚、中国和美国3个国家。线上有超过2.7 milion的数据。

我们的日常交付是从处理不同数据源到展示在我们的网站上这样的端到端的过程。

再看一下我们用了AWS里的哪些服务，刚才说了我们是支持三个国家，一开始其实我们只支持澳大利亚这一个国家。

之后随着业务的扩张，要引入更多的国家。所以我们使用了SQS和SNS。 我们的数据更多，必须选择高可用的服务来支持正常的交付。

我们面临的挑战是什么？

如何基于AWS不同区域进行部署，如何并行的部署？

如何实践持续交付？

对比之前讲到的部署流程，基于AWS的跨区域部署在流程上有哪些区别？打包跑测试的流程几乎都一样，主要是部署不一样。

刚才看到的每个部署环节都只有一个环境，现在除了dev环境外，Staging有三个，我们这里是配成并行的自行触发生产环境，之后会加一个手动的触发，它会并行的同时部署到production的环境。

跨区域的并行部署时如何实现的呢？第一个是基础设施即代码，第二个是流水线即代码。

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

基础设施即代码想希望达到的标准是什么。

一个是标准化，利用代码帮我们定义环境，所有环境的配置都是标准化的，由代码控制、开发、测试和生产。

二是自动化，用工具来自动化准备环境，包括机器的生成、机器的配置以及部署。

三是可视化，用监控来可视化环境信息，环境状态可视，环境变更可视，环境变更可追溯。

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

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

CloudFormation，刚才我说到有几个不同的环境，不同的变量是可以通过配置传递到模板里。

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

举个例子，这是刚才说的除了部署之后还需要建设的，帮我们去跑测试和打包的流程，在这里测试的步骤是什么，构建的是什么，push是什么，我们一般会把build和deploy分开。

Deploy到不同的环境和配置，用代码的方式去定义流水线。

蓝绿部署，设想对于一个dev环境来说，已经有了运行中的代码在EC2上面，当我们触发deploy操作，CI会创建新的cloudformation stack, 将新的代码部署到另一个EC2上面。

之后SWICH的操作，会通过ELB切换到新的EC2，相当于所有的流量都导入到新的里面。当顺利切换后，触发Delete就会将旧的资源全部删除。

Feature toggle 相当于是一个功能的开关，这个开关可以控制这部分的代码要不要正常运行。我们会用E2E Test来管理不确定是否上线的功能。

针对每个环境，E2E的配置可能都不一样，在Deploy和SWICH之间添加E2E测试的环节。将互相有依赖或者主要的功能测试放在这个环节，可以有效的保证线上产品的质量。

本文根据 5月27日西安Jenkins 沙龙演讲整理而成。

企业级DevOps解决方案专场、行业级DevOps解决方案专场于6月29日、30日悠唐皇冠假日酒店举行，现在限时限量赠票。届时将有8位资深 DevOps 大咖于现场与大家分享DevOps落地经验，想要聆听各行业 DevOps 落地方案的朋友可扫码立即报名。

扫描下方二维码立即领取赠票

↓↓↓

现场还有 大会主题T恤等你来拿哦！

点击阅读原文，立即领票！