深刻理解CI/CD：工具、方法、环境、基础架构的全面指南

本文来自Rancher Labs

持续集成和持续交付（CI/CD）是DevOps背后的助推力之一。若是你的企业正在考虑使用DevOps，那么CI/CD绝对是须要考虑的其中一部分。可是CI/CD到底意味着什么？为何它如此重要呢？为了对你的DevOps工具包和IT部署进行战略规划，深刻理解CI/CD相当重要。本文中，咱们将探讨CI/CD所需解决的难点、须要的工具以及预期的收益。

首先，咱们从大局着手。DevOps旨在建立一个流畅的工做流程，并尽量减小越区切换和创建快速反馈回路。这意味着什么呢？工做会从第一步开始一直向前推动，而且在理想状态中，无需倒退再进行修复，由于它们应该可以验证和修复问题。为此，开发人员须要快速的反馈回路。该反馈经过快速自动化测试提供，而且该测试将验证代码在进入下一阶段以前可否按照预期工做。

为了减小越区切换，成员较少的小组将使用较小的功能而且掌控整个流程：建立请求、提交、QA以及部署。其重点是快速推出小段代码，由于变动越小，诊断、修复和补救就越容易。

持续集成（CI）实现了从第一步到最后一步的快速流程，并经过持续交付（CD）将其扩展到实际生产部署。咱们将其称为CI/CD。如今，咱们开始深刻了解它们。

深刻探索持续集成

首先，咱们关注CI/CD的CI（持续集成）部分。实际上，大部分公司仅执行了CI。而完成整个CI/CD，须要该企业已是一个成熟的DevOps企业。

说到集成，咱们指的是程序员在其本地计算机上开发的代码（包括更新或添加新特性）集成到代码库中。这一过程会面临如下3个挑战：

• 跟踪全部变动，以便在发生错误时仍然能够恢复到以前的状态，以最大程度地避免服务中断。
• 当多个开发人员同时在同一个项目中工做时须要管理冲突
• 将新代码添加到代码库以前须要捕捉到错误

接下来，咱们将讨论能够解决以上几个痛点的3个工具。

一、 版本控制

随着代码从开发人员转移到运维人员，它会根据测试结果不断进行调整。全部的更改都会被版本控制系统捕捉。版本控制是一个软件工具能够帮助开发者管理源代码更改。在特殊类型的数据库中它会一直跟踪全部更改。

理想状态下，软件系统的全部部分都会被捕获到，包括：

• 源代码
• 资产
• 环境
• 软件开发文档
• 对系统中存储的文件的任何更改

二、master和开发分支

一般状况下，在同一个项目中会有多个开发人员一块儿工做，多是几我的也多是上百个程序员，所以这可能会致使混乱。为了避免让稳定性遭受破坏或减轻在版本控制主分支中引入错误的风险，每一个开发人员应该并行处理系统的不一样部分。他们经过本地计算机上的“分支机构(branch）”执行这一操做。

可是在分支机构上工做自己并非解决方案，每一个开发人员正在处理的代码必须集成到不断扩充的代码库中。

开发人员在分支机构中工做而无需提交主分支的时间越长，与每一个人在master中所作的更改进行集成和合并的难度就越大。因此，因为开发人员在不提交代码的状况下处理代码的时间越长，得到代码的难度就越大，所以从逻辑上来讲就应该增长提交代码的频率。可是更好的方法是，使其持续集成。

下图描绘了如何可视化不一样分支。蓝色是master分支，其余颜色都是在本身的分支上工做的单个开发人员，这些分支最终合并到master分支中。

不过，就算有分支机制也并不是一路顺风。即便开发人员天天提交代码，冲突仍然会发生。由于其余团队成员会继续作出更改，而没有考虑各方的诉求。实际上，集成问题常常须要返工，包括手动合并冲突的更改。可是比起开发团队整周或一个月都在埋头工做而不处理冲突，找出并解决一天工做中的冲突要简单不少。所以，尽管没法避免集成问题，但CI能够大大减小集成问题。

三、部署流水线和自动化测试

QA的部分工做是找出错误并确保代码是可部署的。传统流程中，在部署完成后会由一个单独的团队来负责QA。由于开发人员一般每一年仅执行几回测试，所以在引入更改几个月后他们才了解到错误。到那时，因果之间的联系可能已经很难查证，致使诊断愈来愈困难。可是自动化测试解决了这个问题。

使用部署流水线以后，每次将代码添加到版本控制中都会触发一系列测试。流水线会自动构建和测试代码以确保它能够按预期工做，而且一旦集成到代码库中就能够继续工做。虽然在测试环境中代码能够完美执行，但它仍有可能在生产环境中不幸失败，由于生产中的环境和全部依赖项都会影响代码性能。依赖项并不属于app中的一部分，但仍须要运行它。例如数据库、数据/对象存储以及服务和应用程序可能须要调用的API。所以，开发和测试环境必须模仿生产环境。另外，必须对全部依赖项进行代码测试。

简而言之，部署代码时有3个测试阶段，每一个阶段都会额外增长复杂性：

（1）验证代码自己是否按照预期工做；

（2）在代码库中继续进行验证；

（3）验证性能在具备全部依赖项的类生产环境中保持不变。

若是代码天天都被提交到版本控制中，则能够对其进行自动化测试，而且在引入代码之日会标记出任何构建、测试或集成错误，从而能够当即进行修复。这确保代码老是处于可部署和可运送的状态，称为绿色构建。

自动测试容许开发人员提升测试和集成的频率——从周期性执行到持续测试集成，并在约束最少的状况下发现问题。最糟糕的状况也不过是一天的工做都浪费了。

关于版本控制的争议

关因而否改在版本控制中存储敏感信息（如 access token、密钥和密码）进行了一些讨论。一方面，有人认为应该将一切（包括secret）都存储在这里，从而将这一方法推向极限。可是有人认为这是不良作法，并认为敏感信息应该单独存储。

版本控制容许开发人员比较、合并和还原之前的修订。经过容许他们在出现问题时将生产中的系统快速还原到之前的版本，从而将风险降到最低。为此，不管版本多小，全部更新和更改都必须在版本控制中进行跟踪。若是不是这样，生产中的代码将开发和测试环境中的代码不匹配，从而致使不一致。

简而言之，版本控制是事实的单一来源，包含了系统的预期状态以及全部之前的状态。经过将全部生产环境中的组件放置到版本控制中，开发人员能够重复可靠地重现工做软件系统中的全部组件。这是启用所谓的不可变基础架构的关键，咱们将在稍后讨论。

持续交付：扩展CI以实现流畅的代码部署

即便使用了持续集成，将代码部署到生产中的过程依旧是手动、乏味且容易出错的。若是真是这样，那么显然不会频繁地将代码部署到生产中。IT部门会尽量避免执行艰巨而危险的任务，这会致使要部署的代码与生产中运行的代码之间差别愈来愈大，进一步加具危险，而后造成一种恶性循环。那么解决这一恶性循环的答案是启用CI/CD中的CD部分。

CD扩展了CI，确保在将代码推广到整个用户群以前让代码在生产环境中可以平滑运行。最多见的CD方法是金丝雀和蓝绿部署。

进行蓝绿部署期间，IT会与当前版本一块儿部署一个新的组件或应用程序版本。新版本（绿）被部署到生产中并对其进行测试，与此同时当前版本（蓝）依旧可使用。若是新版本的代码运行良好，那么全部用户将会切换到新版本中。

金丝雀部署也有两个版本：当前版本和更新版本。IT开始将一小部分用户请求路由到新版本。代码和用户的行为会被持续监控。若是错误率或用户投诉并无增长，则路由到新版本的请求份额将逐渐增长（例如，1%、10%、50%最后到100%）。一旦全部请求都发送到新版本中，那么旧版本就会自动退休或删除。

经过按需环境建立自助服务

如今，咱们已经研究了CI、CD及其各自的工具和方法，下面咱们来讨论环境和基础架构。CI / CD须要一种创新的方法。

如咱们所见，自动化测试使开发人员能够本身执行QA。为了确保一切都能在生产中正常运行，他们必须在整个开发和测试过程当中使用相似于生产的环境。

传统上，开发人员必须向Ops团队请求（手动）设置的测试环境。此过程可能须要数周，有时甚至数月。此外，手动部署的测试环境一般会出现配置错误，或者与生产环境有很大差别，所以即便代码经过了全部预部署测试，仍然会致使生产问题。

CI / CD的关键部分是为开发人员提供按需相似于生产的环境，使其能够在本身的工做站上运行。为何这很重要？开发人员只有在相同的条件下进行部署和测试时，才能知道代码在生产中的行为。若是他们在不一样的环境中测试代码，则当最终将代码部署到生产环境中时，他们可能会发现代码不兼容，那么此时对客户形成了重大影响，再解决问题已经为时已晚。

不可变基础设施：牛与宠物

在讨论版本控制系统时，咱们谈到了将环境与全部其余应用程序组件进行编码的需求，接下来让咱们进一步讨论这些环境。

若是在版本控制中定义了环境规范并进行了编码，那么在容量增长（水平扩展）时复制环境就像按一个按钮同样简单（尽管以后它颇有可能经过Kubernetes自动化了）。

扩展意味着在高峰时段增长计算能力。例如，Netflix的使用率在每一个星期五晚上达到峰值，而后在午夜以后的某个时间再次恢复正常。为了确保享受无缓冲的视频，Netflix复制了其流控制组件（已在版本控制中进行了编码），以知足需求。而后，流量恢复后全部所谓的副本都被破坏，使流容量恢复正常。

为了实现这一点，相当重要的是，每当实施基础架构或应用程序更新时，这些基础架构或应用程序都会自动复制到其余地方并置于版本控制中。这将确保不管什么时候建立新环境，它都将与整个流水线（从dev到QA到生产）的环境匹配。例如，若是Netflix要更新其流服务而忘了捕获版本控制的更改，它将在高峰时段复制有故障或过期的组件，从而致使问题甚至服务中断。

因为掌握了版本控制中的环境编码，所以手动更改环境不是最佳实践，由于任何手动操做都容易出错。而应该将更改放入版本控制中，并从头开始从新建立环境（和代码）。这称为不可变基础架构。这些与CI / CD部分中讨论的应用于基础架构的原则相同。

你也许听过牛与宠物的比喻。这个比喻放在这里十分合适。之前，基础设施被视为宠物。若是有问题，你会尽力解决它，以便它能够生存。今天，基础设施被视为牛。若是它没法正常工做或须要更新，请杀死它并启动新环境。这很是强大，而且大大下降了问题潜入系统的风险。

发布与部署解耦

传统上，软件发布是由市场启动日期驱动的。所以，要发布的新功能会在宣布日期的前一天部署到生产中。可是，咱们知道将特性或更新发布到生产中老是有风险的，尤为是若是你一次发布整个特性时。所以，将部署与发布捆绑在一块儿将使IT部门老是须要为失败胆战心惊。试想一下，若是在普遍推广的前一天发生了重大问题，IT团队就会感到恐慌，而且会在客户和媒体中引发巨大不良反响。

更好的方法是使部署与发布解耦。尽管这两个词常常互换使用，但它们是两个独立的过程。部署意味着将软件版本安装到任何环境（包括生产环境）中。它不必定必须与发布相关联。另外一方面，发布意味着向客户群提供新功能。在整个功能开发过程当中频繁进行生产部署的目的是下降服务中断的风险，该风险由IT部门承担。另外一方面，什么时候向客户展现新功能应该是业务决策，而不是技术决策。

部署周期长会决定新功能发布的频率。若是IT能够按需部署，那么公开新功能的速度应该成为业务和市场营销的决定。

结 论

总而言之，CI要求将代码连续集成到代码库中，以在发生错误时捕获错误，从而最大程度地减小返工。要实现这种方法，须要三个工具：版本控制，以跟踪全部更改并使整个团队均可以使用最新的源代码版本；master，负责本身分支的开发人员天天合并更新；部署流水线将触发一系列测试，基本上是自动进行QA。

CD扩展了CI，以验证代码是否处于可部署状态，并自动将其释放到生产环境中。为此，须要一个成熟的DevOps组织，该组织必须先掌握CI，而后才能尝试使用CD。

若是实施得当，CI（/ CD）将大大提升你的IT团队的生产力。你的系统或应用程序在不断改进，同时将部署风险降至最低，从而加强了生产力和员工满意度的积极循环。此外，快速推出新功能和更新可推进创新，进而更快，更频繁地为用户带来价值。显然，随着愈来愈多的组织采用这些DevOps方法，因为传统方法没法与CI / CD竞争，所以对那些没有采用DevOps方法的企业，压力会愈来愈大。

附录：部署流水线测试套件

• 集成测试检查应用程序如何与其余应用程序和服务交互，以确保代码与这些依赖项正确交互。远程服务的虚拟或模拟版本可用于准确地从新建立生产环境。
• 验收测试会验证是否知足业务需求，以确保功能或应用程序为最终用户提供所需的价值。
• 性能测试可验证该应用程序在相似生产的负载下如何在整个堆栈（代码、数据库、存储、网络、虚拟化）中工做。由架构决策或网络、数据库、存储或其余系统的意外限制引发的问题应在此处解决。
• 非功能测试包括可用性、可伸缩性、性能、容量、安全性等。这些要求取决于环境的正确配置。测试将验证环境是否已正确构建和配置。
• 冒烟测试验证该应用程序能够链接到全部支持系统，例如数据库、服务或信息传递系统；冒烟测试一般是手动的。

也有自动安全性测试以及探索性和其余手动或资源密集型测试。咱们的目标是尽早捕获更多错误，并使用这些更耗时的测试来验证高层次的需求，并将产品彻底集成到尽量接近生产的环境中。