如何防止微服务中的配置漂移

Question

当我开始工作时，每个人都害怕部署。自上一次发布以来，软件很少被部署，人们担心服务和机器会被手工“修补”。

我通过自动化部署和配置部署应用程序时要部署的所有服务来修正这个问题.因此，一切都是频繁部署的，即使没有任何变化。

现在，我们正在考虑转移到Microservices，因为我们需要支持在一个平台上工作的多个团队，使用不同的发布频率。

如何确保足够频繁地部署服务，使人们不害怕部署？

Answer 1

如何确保足够频繁地部署服务，使人们不害怕部署？

首先，尝试理解为什么他们害怕将新代码部署到给定的环境中。

其次，每个人都需要理解部署和发布之间的区别。

发布:定义对最终用户可用的功能的业务术语。部署:适用于团队领域并意味着在Production.部署中引入功能的技术关注点并不一定意味着发布。- 来源

有许多因素可以影响您的方法：

• 你的分支策略
• 你使用的功能开关
• 自动化测试的水平
• 您的CI/CD管道的成熟程度
• 退步的可能性
• 等。

让我来谈谈上面提到的问题。

分支策略

对于git流，您有几个分支：

• 特征分支:那里正在进行积极的开发
• 开发分支:用作特性分支的集成分支。
• 主分支:用作发布历史记录。

换句话说，主分支被认为是一个稳定的代码库，每天都可以安全地部署到一个暂存环境中。

对于特征分支工作流，您没有开发分支。所有功能分支都直接合并到主服务器中。如果没有适当的门控/保护检查(例如:拉请求)，主服务器可以包含中断的代码。

使用特性切换

如果您想部署一个新特性，但不想发布它，那么这就是特征标志发挥作用的地方。

即使新的二进制文件在生产环境中，功能标志也不允许为所有最终用户提供新特性。有了它们，您就可以控制何时发布给定的功能(以及向谁发布)。

自动测试

如果您只有单元测试，那么您的安全网在回归方面并不是很好。即使您的所有测试都是绿色的，您也可以破坏集成(以前是有效的)。

如果您有更高级别的测试，比如集成(测试组件集成)和端到端测试(测试服务集成)，那么您对新版本的信心就会增加。

如果这类测试大部分是由QA团队手工完成的，那么您应该考虑投入时间和精力来编写更高级别的自动化测试。

CI/CD成熟度

我们可以差异化三个不同的级别：

• 连续集成：
  • 有单元、集成、回归(和验收)测试。
  • 自动部署是针对单个环境完成的(通常是临时部署)。没有部署升级。

• 连续部署：
  • 有各种各样的测试(甚至吸烟和精神健康测试)。
  • 自动部署是针对多个环境完成的(如果所有测试都通过，那么部署将提升到下一个环境)，并在生产前停止。
  • 需要人工干预才能部署到prod中。

• 连续交付：
  • 与部署相同，但没有人工干预(审批过程)。

回滚可能性

失败是可以也将发生的。它们是不可避免的。我们是人，我们可以犯错误。所以，即使测试给出的信心，bug也能找到自己的生产之路。

要最大限度地减少影响，最好的办法是恢复到以前的版本。有几种很好的方法可以做到这一点。最著名的两个是金丝雀释放和蓝绿部署.

在金丝雀发布的情况下，您将逐步传播新代码。例如，如果您有4个服务器，那么在第一步只部署到一个服务器(25%)。如果您满意，那么将它部署到第二个服务器(50%)。作为最后一步，您将其部署到其他服务器(100%)。

在蓝绿色部署的情况下，您将提供与生产节点(蓝色)相同的新节点(绿色)。将新代码部署到所有绿色节点。将这些绿色节点注册到负载均衡器中。你允许蓝色和绿色的交通。如果您满意，那么从负载均衡器中删除蓝色节点。如果不，那你就把绿色的拿掉。