CI/CD在aws上的最佳实践

1.首先什么是CI/CD？

CI-持续集成（Continuous Integration，简称CI），是为保证不同功能的开发人员所贡献的代码保持同步，通过自动测试、验证与反馈的方式实现开发工程师之间的协同。比如说开发团队将自己的代码库

都放在Gitlab上，然后每个开发人员都Fork了一个副本在本地做开发测试，最终我们希望将每个开发人员的代码段集成到主分支（master）上，在这之前我们需要创建测试案例保证程序不仅可以单步

运行，也可以按照主分支的逻辑运行不至于影响其他模块。在持续集成的场景中，开发人员可以不断拉测试案例来验证程序运行正常，与主线兼容良好，不会在发布时有巨大改动。

CD-持续部署（Continuous Deployment，简称CD），是将持续集成所编译的程序部署到环境上，持续部署的环境可以是某个特定项目的多个场景，比如说开发环境（Dev Environment）、

测试环境（Test Environment）、生产环境（Production Environment）等。当然也包括了各个环境中的高可用、负载均衡等场景。

CI/CD的出现并非只是为了顺应软件开发和运维应该协同合作的理念，更大程度上它是为了能够更频繁地发布高质量的软件，并通过促进沟通和协作来实现这一目标。

2.CI/CD在SilverLining中的实践

在SilverLining, 持续集成和持续部署的工具有Gitlab源代码管理器， Atlassian Jira和Jenkins。我们拿开发ProtecEasy项目来举例，首先开发Leader会把一项复杂的功能分解为几项子任务，

并在Jira中录入，分派给相应的工程师。开发工程师在完成一项功能后，需要做本地单元测试。通过了单元测试测试才能说明本地开发完成。接下来我们需要拉取一些集成需求，这些需求是要将

本地代码段并入总线（Master Branch）前的一组测试案例，包括安装、测试案例执行、语义分析、单元测试和评论（为和项目组其他成员协同开发，必须兼容评论功能）。

代码并入Master Branch后，会在Jenkins上触发自动化集成测试。我们会继续测试包的安装、构建、创建缺陷、创建版本、推到‘提交’阶段（提交阶段是持续集成和持续部署的分水岭）。

然后进入部署阶段，Jenkins会从‘提交’库中获取安装包，继续在负载均衡测试、并发连接测试、应用安装、验证和提交。在负载均衡环境有测试人员，甚至会有最终用户，完成全部功能点的测试之后会

提交进入生产环境。

3.aws公有云引入CI/CD的实践

SilverLining在实践CI/CD过程中发现aws云是CI/CD的实现的有用助手。 在接受SilverLining产品总监offer之前，我个人曾在中美两国很多不同软件开发团队工作过，包括硅谷的独角兽创业公司，

美国的大型电商公司，也有中国大型央企等。我发现在很多企业在实践CI/CD中的难点是如何将应用和测试代码部署到基础设施，这是因为团队需要调配和部署基础设施，要求网络工程师、IT 运维和

系统管理员了解相关技术，将软件和硬件组合在一起，建立网络，创建虚拟机并将它们交给开发人员或运维人员去配置，然后再让其他人在上面部署应用程序。这一过程需要由多人来处理，并依赖大量的

人工劳动，即不稳定、耗费时间，还会引入额外的成本。

而SilverLining作为aws的premier partner我们所有的服务包括CI/CD都是基于aws来实现。我们发现在aws上配置一台CI/CD服务器，运行15分钟后关闭，你只需要为此支付 15 分钟的费用。

和上述传统方法相比相当灵活，高效，节省成本。另外使用传统物理硬件来测试基础设施代码会有所限制，因为不是每个人都可以访问到它。aws云将CI/CD的实践大众化，并将其优势转化为企业运营成本。