最初发布于MetalBear 博客。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--CY7y8RcR--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/0g92u051f0vdd9933kx6.png)

开发循环(或:了解你的敌人)

[](https://res.cloudinary.com/practicaldev/image/fetch/s--iOryIIqY--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to -uploads.s3.amazonaws.com/uploads/articles/ifc7f9wh8azjdoa65j7g.png)

想象一下,你是 B SaaS soonicorn 的后端开发人员。您已经花了半个 sprint 为您的微服务添加新功能。您已经彻底研究了可能的输入和数据库状态,并构建了一个精心设计的测试套件。你的代码被你的两个队友无情地审查了。最后,测试通过,拉取请求被批准,作为最终验证,您将新代码部署到暂存环境......

它几乎立即崩溃的地方。结果你忘了测试一些晦涩难懂的配置,或者一些复杂的数据库状态,这些状态只会出现在成熟、复杂的环境中——比如登台,与你的本地机器不同。

因此,您在 staging 中回滚服务,修复错误,编写更多测试,再次对其进行审查,构建代码,将其部署到 staging......然后它再次崩溃。当您修复错误时,您的队友部署了其他一些微服务的新版本 - 除非他们不像您那样彻底的测试人员,并且新版本已损坏,因此您无法测试自己的服务。您等待他们将服务回滚到工作版本,冲刺早已结束,并且您已经在停机期间开始了下一个功能,所以现在您将注意力集中在两件事上。

最糟糕的是,你知道它会在下一个 sprint 再次发生。

镜像(或:你如何获胜)

在我工作过的每个初创公司中,我都遇到了一些开发循环的变化,而这正是我们试图用 mirrord 解决的痛苦。 mirrord 在两个地方运行 - 在您的本地开发机器上和在您的暂存环境中。通过包装您的本地进程并挂钩系统调用,它可以让您以非侵入方式将您的进程插入到暂存环境中的该服务实例中。

简单地说,mirrord 让您可以在云服务的上下文中运行本地进程。这意味着您可以在暂存时测试您的代码,而无需实际部署它。它不仅可以在您每次进行更改时为您省去部署的麻烦,而且还可以使暂存环境免受未经测试的版本的影响,并且可以持续供组织中的其他所有人使用。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--nJ_8ADhL--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/dt51lnzabke5phsh35or.png)

入门(和:其他实用信息)

今天我们发布mirrord 2.0,它支持传入流量。这意味着在暂存中到达您的服务的任何流量都会被镜像复制并发送到您的本地进程。我们很快将添加对传出流量、文件访问和环境变量的支持——本地进程“认为”它在暂存环境中运行所需的一切。

运行 mirrord 所需的只是 kubectl 访问暂存环境1。您可以将其用作 CLI 工具或 VS Code 的扩展(即将提供 IntelliJ 支持)。在此处尝试,并在hi@metalbear.co或我们的仓库中告诉我们您的想法!

1. 请注意,mirrord 不会在您的 Kubernetes 集群中安装任何持久性内容。它运行一个在镜像终止时自删除的作业。↩