大约一年前，我们开始为CloudBees DevOptics开发runinsights特性。在过去的一年里，一个由工程师组成的小团队（平均大约3到4个人）在runinsights服务上工作。RunInsights服务让我们有机会从一开始就使用连续部署来开发新的服务。一年后，在343次部署之后，我认为分享我们从经验中学到的东西是个好主意。CloudBees Devptics运行Insights架构在我们希望从一开始就使用连续部署的基础上，我们做出了几个设计决策。在进行连续部署时，无法控制部署新版本的时间。部署期间的任何停机时间都不会让我们的用户感到高兴。这意味着您需要零停机时间部署策略。我们决定将runinsights作为一个单独的微服务来实现，以控制它自己的数据存储，并使用蓝绿色的部署模型。蓝绿色部署模型意味着在部署期间，服务的旧（蓝色）和新（绿色）版本都将服务于流量，这样我们就可以在销毁旧版本之前预热新版本的实例。如果在部署过程中遇到新版本的问题，我们可以放心地终止新版本，因为我们相信用户将继续得到他们的请求。在选择蓝绿色部署模型时，我们需要考虑数据存储中的数据模式。新版本的服务将发展数据模式，我们希望这种演变是自动化的。我们的方法是以这样一种方式对模式进行更改，使模式始终可以被以前部署的版本使用。我们的大部分架构更改都是添加新的列或表，这不会破坏旧版本。对于突破性的更改，我们尝试将它们分成一系列部署。例如，如果要重命名SQL表中的列，则可以使用一种方法来处理重命名：创建备份表的临时视图，并更新代码以直接使用该视图而不是表重命名列、更新视图并更新代码以使用具有新列名的表删除视图虽然这不像重命名列那么简单，但它具有这样的属性：每个部署都可以与前一个部署同时运行。我们有三种不同的数据存储：PostgreSQL用于需要事务一致性的数据。我们使用FlywayDB来管理模式。Elasticsearch用于运行Insights用于报告的度量数据。我们能够使用别名和我们自己的定制模式迁移代码来处理我们存储在Elasticsearch中的数据所涉及的非常具体的模式迁移子集。Redis被用作更昂贵的计算结果的缓存。我们使用版本字符串作为键前缀的一部分来管理Redis缓存中对象的模式。如果架构发生更改，则缓存中会有两个版本，直到旧部署停止。通过以上两个方面：蓝/绿部署和模式管理，我们发现了一条用于代码库的黄金法则：永不后退，只向前走。部署比当前blue版本旧的版本将需要恢复PostgreSQL和Elasticsearch数据（以回滚架构版本更改），这将导致数据丢失和大量停机。这就直接把我们带到了部署的主题上。我们从主分支自动部署。我们考虑了其他方案，例如，在我们启动时，CloudBees DevOptics Value Streams服务更多地使用GitOps风格的流，并通过将更改推送到生产分支来触发部署。我们想要的是利用合并到master将部署到生产中的知识，以提高代码质量，并确保工程师在合并之前能够编写好的测试。我们有三种类似生产的环境，它们都具有蓝色/绿色部署功能：集成登台生产集成环境和登台环境之间的主要区别是应用于登台环境的安全控制和操作策略。我们应用于Staging环境的附加控件允许我们将生产数据转储加载到Staging中，以便在需要验证包括数据变异的模式迁移时使用。我们的部署流程有点像这样：注意事项：我们运行负载测试和验收测试作为每个环境中每个部署的一部分。如果测试在特定环境中失败，我们将停止新版本，而让旧版本服务于流量。如果部署在登台或生产中失败，我们只恢复该环境，而不恢复以前的环境。这个部署模型意味着所有的特性开发都是通过拉请求进行的。什么有效蓝绿部署这太棒了。我们的计划外停机时间为零。我们有计划的停机时间，例如，当操作需要进行基础结构更改时，停机时间无法避免。 持续部署文化一旦您知道合并Pull请求意味着代码将最终投入生产，您就可以编写测试，始终如此。测试是唯一能阻止被破坏的代码最终投入生产的方法。这个简单的事实在心理上改变了你对测试的看法。因为失败的测试会停止部署，所以我们对片状测试毫无怜悯之心。当我们发现一个不完整的测试时，它就会被修复或重写。部署已成为非事件。在合并之前，pull请求得到了Jenkins的验证。因为我们有很好的测试，拉请求验证是值得信赖的。一般来说，我们只需合并pull请求并继续进行：最坏情况下，Jenkins会在生产之前向我们发送一个失败通知，然后我们就可以解决这个问题。尽管如此，我们还是尽量不在周五下午合并pull请求。 验收测试停止了损坏的部署我们并不完美。有时当我们合并一个请求时，验收测试将失败。一个例子是关于身份验证的：拉请求是在一个没有连接到我们真正的身份验证服务的丢弃环境中进行验证的。这意味着我们不能运行一些验收测试作为拉请求验证的一部分。但是，我们的验收测试可以捕捉到这些问题，并防止部署失败。出什么问题了Elasticsearch架构迁移我们定制的Elasticsearch模式迁移代码的第一个版本基本上是一个500行的巨型函数。我们进行了黑盒测试，验证了所有的工作，覆盖了所有的逻辑分支，代码覆盖率很高。但是，有一个计时错误，只有在有大量数据需要更新时才会出现（比如几个月内）。我们的测试用例使用的生成的数据只有几个数据点，因为如果我们必须注入大量数据，这些数据将运行缓慢。当上线后的第一个架构迁移的生产部署失败时，会很有趣。我们为green节点启动的应用程序在模式验证期间失败，因为模式验证代码无法完成。结果谢天谢地，我们的蓝绿色部署意味着蓝色节点仍在服务于客户请求，我们能够将500行的巨型函数重构为一个更易于测试的小函数组合。更多的测试意味着我们发现并修复了计时错误（不需要大的测试数据集）我们需要根据生产请求对数据库的转储和拉取请求进行验证测试覆盖率差当我们添加了按master过滤Run Insights的功能时，其中一个端点只进行了一次"冒烟测试"。当前端团队开始添加UI来实际调用这个端点时，他们发现了实现中的一些bug。糟糕的测试覆盖率意味着我们在生产中部署了破坏代码。谢天谢地，这不是面向用户的，因为使用新端点的更新的前端尚未部署。结果我们添加了更多的测试，发现并修复了错误，并重新加强了我们总是编写测试的文化。想了解更多关于CloudBees Devptics的信息吗？注册免费试用额外资源阅读有关可视化价值流的更多信息了解如何测量DevOps性能了解有关CloudBees DevOptics功能的更多详细信息