从三层部署模型到持续集成部署和容器部署 - JAXenter


著名的3层模型(如果有预算,有时甚至是4层模型):

  1. 开发是在通常在每个开发人员的本地笔记本电脑上编辑代码的地方。
  2. 测试是多个开发人员的代码第一次相互看到。在这里进行集成测试,用户接受测试和其他质量检查。有时这与暂存合并。
  3. 暂存是一个预发布的存放区,用于在与生产类似的环境中测试代码。
  4. 生产就是生产。实时站点。


3/4层模型的优势在于,代码可以在到达实时站点之前被多个人检查和测试。代码编写发生在dev中;代码合并发生在测试中;质量检查发生在测试中;最终审核发生在暂存中,有时带有生产数据快照;而生产是客户实际查看站点的地方。

但是,三层模型也有许多缺点。特别是,本地开发很容易远远落后于Testing实例,从而导致Testing变成大量合并冲突。您等待的时间越长,将代码合并到“测试”中就越难。另一方面,合并到测试的频率越高,测试就越困难。每当合并一些新代码时,被测试的对象都会更改,从而导致目标移动。当您有多个测试人员时,这将成为更大的挑战,因为他们的努力可能会相互碰撞。

该模型的另一个主要缺点是它是线性的。果您发现生产中的错误,那么绕过测试/阶段管道并直接部署到生产中而不验证该修补程序不会破坏其他任何东西都是不好的形式。

另一个问题是数据。当代码在管道中向上流动时,您希望能够使用当前生产数据测试新代码。根据设置,将生产数据的快照获取到暂存的过程可能很困难并且很耗时。如果是这样,将其复制到测试或开发中将更加糟糕。这意味着您可能直到最后一分钟才发现新代码如何与实际数据进行交互,这通常要比您想要的晚几个星期。

持续集成/持续部署
应对三层模型挑战的标准解决方案是更快地推动变化。这导致了两个孪生概念:

  • 持续集成(CI),大致可转换为“使代码尽快集成到测试中”。
  • 连续部署(CD),大致可翻译为“通过管道获取代码并尽快将其部署到生产中”。

众所周知,CI / CD试图通过自动化解决3层模型的挑战,以便更快地通过过程获取代码。那可能需要许多不同的选择。
  • 在将新代码部署到任何地方之前,自动对新代码运行代码级测试。
  • 在“测试”中自动运行一些QA或UAT测试,从而减少了对慢速和忙碌人员的需求。
  • 当满足某些条件(例如通过测试)时,通过管道自动推进代码。

这有助于减少将代码推入管道所需的时间,但并不能消除核心问题:3层模型是线性的,而代码开发却不是。它还提出了自己的挑战,即必须设置,管理和保持工作的更多活动部件。对于CI / CD工程师,“ DevOps工程师”或其他各种各样的职位,甚至还有特定的职位角色,这些职位实际上意味着“对所有自动化进行维护和提供”。这似乎不是很自动化,但代价可能很高。

进入容器
CI / CD自动化可以容忍两项技术进步。
首先是Git作为版本控制系统的广泛普及。较新的开发人员可能不记得Subversion或CVS的时代了,但是在现代分布式VCS之前,“创建分支”曾经是一项艰巨,耗时的工作,因此是罕见的任务。Git方便地解决了这一问题,简单的API使其非常适合脚本编写和自动化。

第二个是虚拟化的出现,首先是通过虚拟机,然后是通过容器,甚至更好。容器使您可以从物理硬件中抽象出计算机“系统”的概念。这意味着构建新环境不需要构建新硬件,只需编写足够的代码即可。

长期以来,容器主要用于廉价的测试环境。CI服务如雨后春笋般涌现,这些服务使用容器来构建临时的微型系统,以在其中运行代码级测试或有时进行完整的UAT测试。结合基于Git的自动化,使传统管道的“测试”阶段变得更加简单和高效。

但是,此类服务无法解决3层模型的核心问题:线性特性。它仍然只是使其速度更快。
此外,在大多数情况下,生产系统仍未与开发或测试保持同步,有时甚至与登台也不同步。

容器的最佳做法
,传统的“最佳实践”已经改变。随着广泛的Docker化的出现,当今领先的“最佳实践”是基于从头到尾的整个过程的Docker化。反过来,这又炸毁了传统的3层模型。
相反,今天的最佳实践部署策略如下所示:

从开发到生产的每个步骤都使用容器构建,并通过Git管理。每个分支都对应于基于容器的环境。
环境的配置本身就是存储在Git中的代码,这使得测试基础结构的更改(升级依赖项,数据库或语言运行时)与测试代码更改相同。
对Git分支的所有新更新都可以而且应该导致从头开始重建相应的环境,因此没有要考虑的“就地更新”问题。
与三层模型相比,此Git-and-Cloud模型具有许多优势。

  1. 这是非线性的。一个更改不能阻止另一个更改,因为所有更改都有自己独立的管道。一个功能发布,一个重要的错误修复,一个例行更新,所有这些都可以并行进行,并且每次完成时都可以独立部署。
  2. 并行工作的数量仅受您可以创建的容器数量的限制。假设您使用的是虚拟化云环境,则意味着您在更多环境中的增量成本较低,并且近似线性扩展。
  3. 因为每个环境都是一次性的,并且是根据可重复的说明即时构建的,所以您的预发布环境可以与生产完全相同。
  4. “集成”仅是您要如何使用Git分支的问题。当新的变更合并到生产中时,任何其他分支都可以轻松地合并master上的更新,因为Git使之很容易。如果发生冲突,它将立即被抓住。
  5. 另外,您还可以拥有一个用于发布前测试的Git分支,将该分支合并到其他分支中以进行集成测试。也就是说,如果需要,此模型允许您模拟较旧的3层模型。通常这不是必需的,但在可行的情况下可用。可能的工作流程仅受您团队使用Git的技能的限制。
  6. 因为文件系统是只读的,所以您可以确保不经过Git便无法进行任何更改,并且可以保证额外的安全层可以防止入侵者的入侵。

Git-and-Cloud模型的主要缺点是支持它的基础工具的复杂性,而这种复杂性最好由能够大规模管理该工具的专门团队来处理。
这样就可以在几分钟或几天内使用生产数据和生产配置测试新的更改(无论是小的bug修复,大型的新功能还是依赖性升级)。它提供了最精确的“分阶段就像生产”体验,同时完全避免了“分阶段”服务器的概念。
这就是当今最前沿的部署过程。