2020年持续交付专家检查– CI / CD，安全性和滚动部署（第1部分）

持续交付和持续集成远远不只是流行语或新兴趋势。自动化的发展势不可挡，特别是在DevOps领域。但是，来年CI / CD将如何发展？为什么持续交付软件如此重要？对于2020年的大型持续交付专家检查，我们就这些主题和其他主题向该领域的7名受尊敬的专家进行了询问。在我们的专家检查的第一部分中，查看哪些最佳实践可以帮助确保安全性，以及我们的专家更喜欢哪种部署类型-蓝色/绿色部署或滚动部署？

JAXenter：持续交付是每个DevOps努力的关键组成部分。您为什么认为它起着如此重要的作用？

特雷西·米兰达（Tracy Miranda）：最近有一位朋友分享说，他正在更换银行，因为他过去常常很难通过银行进行网上转账。对我来说，这是一个生动的例子，说明软件已成为大多数行业的主要差异化因素。如今，大多数企业都需要弄清楚如何更快地交付新功能，同时又要确保服务的牢固性和安全性-这就是持续交付的意义所在，以及为什么今天如此重要。

Priyanka Sharma：现在每个公司都是一家软件公司。技术赢家和输家的最重要决定因素是软件交付和迭代的速度。通过利用连续交付，工程团队可以准备要生产的功能，然后通过隐喻性地单击按钮即可将其投入使用。根据我与GitLab客户交谈的经验以及GitLab自己的工程实践，人们可以从几周或几个月一次部署到每天持续交付。

Clark Boylan：持续交付可确保您的软件始终可发布。这使您可以制作许多易于使用的小型发行版，而不是需要大量部署的大型发行版。这样可以更轻松地发现发生故障的地方以及在必要时的位置。最终结果是可靠性和一致性。

Baruch Sadogursky：有一个简单的答案，一个更有趣的答案。简单的答案是，当我们谈论消除障碍并改善团队内部的整合时，消除孤岛意味着更快地行动。加快速度的关键方面之一是消除手工工作并使所有工作自动化。持续交付是动员软件交付的关键组成部分。我会说，更有趣的方面是，它以帮助提供价值的方式为DevOps做出了贡献。DevOps的最终业务目标是提供价值，持续交付可以改善价值的两个方面。

首先，它有助于专注于价值本身，新工作以及对客户重要的事情。消除了手工和繁琐的工作，最大程度地减少了错误，提高了质量。最终，人们在没有价值的工作上花费的时间更少。持续交付的另一个观点是，它可以快速提供价值。今天，在我们这个非常苛刻的市场中，提供价值比竞争对手更快的组织赢得了胜利。这就是为什么连续交付有助于提供更好的结果的原因。

这对于提高安全性也很重要，因为缓解安全漏洞的步骤之一就是将补丁交付到系统的速度。再说一次，谁能更快地交付这些补丁，谁就会比其他人更好，更快地生产。

JoonasLehtimäki：如今，公司要想在业务上取得成功就必须快速高效。我认为，旧数据中心/系统管理员的手动工作已经结束。公司需要一种方法可以在任何地方（一天可能多次）可靠地交付软件，而CD在其中起着重要的作用。

尼尔·科伦（Nir Koren）：我认为当今的开发人员真的不希望花费大量时间手动部署到所有环境，而是希望在云上即时开发并观察成果。从公司的角度来看，这绝对是交付速度（包括功能和错误修复）。

Christian Uhl：持续交付的自动化方面使团队摆脱了以前存在的许多运营负担。这使我们能够将大量时间重新投入到更有价值的活动中。但这只是冰山一角-成功实施连续交付将为企业带来纯净且可衡量的竞争优势。降低风险和缩短上市时间是每个组织都应在这方面努力变得更好的原因。

JAXenter：持续交付是谈论持续提供软件时最常用的术语，但是也存在持续部署和持续集成的问题。你最喜欢什么风格？为什么？

特雷西·米兰达（Tracy Miranda）：可以肯定的是，有关条款一直存在困惑。在理想的情况下，持续集成和持续部署是软件交付生命周期中的全自动部分。完全自动化很难实现或受到法规要求等限制。对于连续交付，重点是工程方法，团队可以在短时间内生产软件，以确保可以随时可靠地发布软件。重点似乎发生了微妙的变化，但实际上却有所不同，因为重点现在已经很容易地包含了人为因素和团队在软件交付中的关键作用。

Priyanka Sharma：持续集成，交付和部署都是同一过程的一部分，以加快软件生命周期。让我们定义每个以确保我们理解这些术语。

持续集成：这是开发人员每天定期且有规律地将代码合并到master分支中，而不用等待“发布日”。为了成功做到这一点，大多数组织利用持续集成管道，通过创建构建并针对该构建运行自动化测试来验证开发人员的更改。尽管运行自动化测试不是持续集成管道的前提条件，但这是最佳实践。GitLab是持续集成管道的狂热用户（和提供者）。

连续交付：组织运行连续集成后，他们还可以自动化其发布过程，从而只需单击一下按钮即可进行部署。对于希望快速敏捷的公司，但由于法规或业务原因而无法进行连续部署的公司，连续交付是一个不错的选择。GitLab属于这一类，因为我们需要手动部署（每天进行一次）以满足合规性要求。

持续部署：当组织具有持续集成和交付的功能时，他们可以通过部署来自动化整个过程，而无需人工干预。持续部署是软件开发人员的必杀技，因为推送到生产的提交不会上线的唯一原因是测试失败。对于许多公司而言，由于合规性原因，完全自动化是不可行的，对于他们而言，连续交付是次之。

克拉克·博伊兰（Clark Boylan）：这三个因素共同作用，并且是运转良好的机器的必要组件。持续集成是您的第一道防线。在这里，您要尽早发现问题，最好是在合并代码提交之前在更改合并之前发现问题。假设提交了CI Gates代码，则您的软件分支应始终处于接近可释放的状态。这有助于持续交付，因为使发布所需的工作量最小化，从而实现了发布过程的自动化。最后，您的持续部署自动化可以消耗您持续集成和交付工具的输出，直接进入生产。每层以非常互补的方式馈入下一层。

Baruch Sadogursky：在这里我要说的是，它们并不是同一事物的不同风格。它们是连续管道的逐渐演变。连续集成是通过以非常快的速度自动进行连续集成来消除手动，繁琐和容易出错的工作的一项。持续交付通过将发行版本交付给目标服务器来自动化另一个繁琐的过程。持续部署是向前发展的一步。现在，我们不仅可以持续制作发行版，并且能够将发行版交付给目标服务器，而且实际上，我们每次都可以连续进行发行，从而省去了另一个手动步骤。

因此，很难回答这个问题。我最喜欢什么？它们显然都有价值，它们都是必需的。有人可以说，持续部署应该代替持续交付。我倾向于同意。手动步骤越少越好。但是持续集成绝对不是偏好问题。持续集成是强制性的；这是持续交付和持续部署的一部分。

现在，您在问题中没有提到另一个连续的问题，但是我想提出：连续更新。这是连续部署后的下一步发展步骤。所不同的是，我们现在知道，不仅我们将新软件部署到服务器上，而且实际上将对现有服务器的更新部署到任何边缘设备上。那可能是您自己在Prem或云中控制的服务器，也可能是我们无法控制的边缘设备，例如移动设备，IoT设备，基站塔中的计算代理。

所有这些都是需要更新的方面，并且显然可以应用通常的持续集成技术，但是您需要超越持续交付和持续部署的范围，并实际实施持续更新。所有这些都是进化，并且大多数都包含在另一个之中。因此，这实际上不是个人喜好或风格的问题。

JoonasLehtimäki：是的，有很多术语，我经常发现人们感到困惑。我通常喜欢使用整个CI / CD术语，因为如果我们仅谈论连续部署，那么它仅涵盖软件管道的部署阶段。持续集成执行自动化测试，构建以及将软件部署到生产之前所需的任何软件。

Nir Koren：持续集成是所有人的基础。没有健壮和适当的CI，您将没有CD（交付/部署）。我最喜欢的方法是“连续部署”（在其中具有包括生产部署在内的全自动化流程），因为它会迫使您提供更稳定，更健壮的环境和测试框架，并使生产更加动态。持续部署使开发人员具有能力，并使他对整个过程负责。

克里斯蒂安·乌尔（Christian Uhl）：我不会称其为不同的样式，而是更多的概念相互依存–持续集成是持续交付的要求，这是持续部署的基础。

JAXenter：就交付软件而言，安全性也是一个非常重要的主题–我们的应用程序不仅应尽快可用，而且应尽可能安全。关于如何在CI / CD管道中实施安全方面，是否有最佳实践？

特雷西·米兰达（Tracy Miranda）：指导原则是“在安全性上左移”，这在《加速》一书（软件交付的圣经）中得到了很好的总结，该书讨论了将安全性集成到软件开发的设计和测试阶段。此外，还有许多安全原则可应用于您的特定CI / CD管道和环境。例如，对于云原生CI / CD管道，Cosmin Cojocar进行了精彩的演讲，概述了原理，例如建立安全默认值，最小化攻击面–然后通过使用配置作为代码，隔离集群，给出了使用Jenkins X的特定方法。等等。我强烈建议您先了解一下这些原理，然后研究如何将这些原理应用到您的设置中。

普里扬卡·沙玛（Priyanka Sharma）：绝对！如果我们回想一下新闻中最近发生的安全漏洞，在大多数情况下，它们并不是复杂攻击的结果。相反，它们是团队出于各种原因而无法遵循最佳实践的情况。因此，至关重要的是将安全性纳入CI / CD管道中，以便开发人员可以在常规部署中检查问题。这使得安全问题与其他类型的失败测试或错误相差无几，因为它在提交和合并代码时发生。

管道中可以包含安全测试和扫描的许多元素。这是一个清单：

1. SAST –静态应用程序安全测试–在部署之前扫描应用程序源代码和二进制文件以发现潜在漏洞

2. DAST –动态应用程序安全测试–通过运行实时攻击来分析运行中的Web应用程序是否存在已知的运行时漏洞

3. IAST –交互式应用程序安全性测试通过检测代码并检查错误条件来检查应用程序的运行时行为

4. 依赖项扫描会分析外部依赖项（例如Ruby gems之类的库），以了解每次代码提交时的已知漏洞

5. 容器扫描检查Docker映像中应用程序环境中的已知漏洞

6. 许可证合规性根据代码提交搜索项目依赖性，以检查每个项目的自定义策略定义的已批准和列入黑名单的许可证

Clark Boylan： CI / CD管道中的安全性必须从CI / CD系统本身的安全性开始。我们看到像Zuul这样的专用CI / CD工具假定开发人员不一定值得信任，并以此为基础建立了安全模型。这有助于确保CI / CD系统不是安全威胁模型中的薄弱环节。除此之外，由受信任的人员执行的代码审查和自动化工具可以协同工作，以防止将不安全的更改合并到您的软件中。

Baruch Sadogursky：保护应用程序安全需要持续交付，持续部署和持续更新。将补丁发布到设备的速度越快，您的安全性就越高。另一方面是管道本身的安全性。我们已经看到了很多供应链的示例，这些示例是您连续不断的管道中的一部分，受到了攻击。我们行业中有一些公司可以保护您的管道和供应链。您不能忘记这方面，因为它实际上是通过管道将可行的组件带入产品中。因此，是的，您的供应链安全是一个重要的方面，需要考虑，资助和实施。

JoonasLehtimäki：从体系结构规划到生产，都应考虑安全性。您可以在管道中快速使用每个可以快速运行和自动化的安全工具，例如，使用Clair扫描图像，然后将其用于登台/生产环境。

Nir Koren：除了显而易见的手动代码审查和安全检查之外，我们使用WhiteSource之类的自动静态代码分析，并不断寻求其他方法来保护我们的产品。

Christian Uhl：可以通过构建SAST（静态应用程序安全测试）和DAST（动态应用程序安全测试）来很好地抓住成果和明显的错误。此外，我们可以（并且确实）包含将在发布更新后自动更新依赖项的服务。这为我们提供了一个尽可能最新的系统，并且我们不会错过产品所有级别的安全补丁。每天部署10次时，更多的依赖关系更新部署将不再起作用。在代码检查过程中包括安全性最佳实践也可以帮助我们发现问题。但是，老实说，我们仍然会在CI / CD管道之外对系统/渗透测试进行手动安全审核，因为总是存在未知的问题。

JAXenter：蓝色/绿色部署和滚动部署之间有什么区别？你更倾向哪个？

特雷西·米兰达（Tracy Miranda）：我喜欢我的同事Viktor Farcic如何将蓝色/绿色部署描述为“肮脏的”部署策略。在部署前的虚拟机，Docker和Kubernetes时代，这种策略很有意义，因此最好还是让旧版本并行运行，以防万一。借助现代应用程序和Kubernetes等云原生平台，滚动和Canary部署在成本效益，高可用性，响应能力等方面更具意义。有关为您的用例选择最佳部署策略的更多信息，我强烈建议您最近使用Viktor在FOSDEM上有关“选择正确的部署策略”的演讲。

普里扬卡·沙尔玛（Priyanka Sharma）：蓝色/绿色和滚动部署是组织将新功能发布到生产中的两种方法。蓝色/绿色部署意味着应用程序有两个环境，其中负载均衡器用于将流量从一个环境路由到另一个环境。蓝色环境是代码的原始版本，绿色是新版本。一旦绿色环境通过所有测试，负载均衡器便可以将流量从蓝色重定向到绿色，并且如果存在任何错误或问题，则可以将流量重定向回蓝色环境。滚动部署是指新版本的应用程序以增量方式逐渐替换旧版本的应用程序。新版本和旧版本共存而不影响功能或用户体验。通过此过程，可以更轻松地回滚与旧组件不兼容的任何新组件。

Clark Boylan：在我们的世界中，重点是项目门控。这意味着我们在合并之前检查每个提交，以确保它不会引入回归和错误。这个想法是为了避免生产中的问题。现实是，仍有一些问题仍会解决，这在蓝色/绿色或滚动部署可能会有所帮助。在蓝/绿部署中，您将在新环境和旧环境之间部署第二个环境。一旦测试表明新环境正在运行，您就可以在生产环境中切换到新环境。

通过滚动部署，您可以一次更换系统的一小部分，从而可以及早发现任何错误，并在必要时进行回滚。在这里，策略的选择通常取决于所部署的软件。整体软件通常更适合蓝/绿色部署，因为它无法分解为较小的部分。基于微服务的可轻松替换的软件使滚动部署成为一个不错的选择。

Baruch Sadogursky：向这些平台交付将为您带来新的机会。当我们谈论容器和无服务器时，我们所谈论的是轻量级更新，这些更新可以替代以前使用的较重的服务器部署或虚拟机设置。现在，当我们需要替换或更新应用程序的一部分时，我们实际上可以实现连续更新，而仅实现系统的一小部分。只有一个图像会缩放到容器，只有一个lambda会缩放，这在我们的无服务器应用程序中是微服务。交付较小的零件可以使我们更快地更新。这就是帮助更快地带来价值并帮助应用程序更安全的原因。容器，Kubernetes和无服务器是个好消息，因为它们使我们能够从持续部署和持续交付整体组件到持续更新微服务的较小部分。

JoonasLehtimäki：主要区别在于，蓝色/绿色部署有两种环境，而滚动部署只有一种。蓝/绿被认为是一种较安全的实施选择，但它有一些开销。在蓝/绿部署中，您将启动一个较新版本的环境，然后开始缓慢地负载平衡该环境的流量。部署结束后，将保留或终止旧环境。然后，滚动部署将使用一种环境，并开始一个接一个地杀死和旋转实例，直到所有实例都处于最新版本。对我来说，我更喜欢滚动更新，但这全部取决于软件和SLA的需求。

克里斯蒂安·乌尔（Christian Uhl）：简短而又不详尽的解释是：蓝色/绿色表示并行运行部署的旧版本和新版本，使实例增加一倍。在某些时候，您需要将某些路由从旧路由切换到新路由。系统的使用者可以看到一个或另一个版本。对于滚动式部署，您需要具有多个部署实例，并且一次更改/更新一个实例–因此，在部署期间，消费者有时会看到旧版本，有时会看到新版本。

两者都有优点和缺点：对于有状态服务（例如数据库），我更喜欢蓝色/绿色，以避免一致性问题。使用滚动部署可以更快地部署无状态组件，并减少资源分配。这样，当新系统中发生太多错误而所有用户都没有受到影响时，就可以放弃部署。