开发服务网格解决方案，使开发人员能够部署和测试多个代码版本

Question

我遇到过这样的情况：我们在 PaaS 中部署应用程序，并且环境仅限于非产品。 我们拥有的环境是 NP、Staging、SIT 和 PROD。

开发人员将继续在本地进行开发和测试，当宣布发布时，NP、Staging和SIT等环境将被完全锁定，发布将持续一周。 在完成对 PROD 的部署并且环境可供下一个版本使用之前，开发人员无法对 NP、Staging 或 SIT 环境进行任何部署。环境可用后，他们部署后只能在实际 np、staging 或 SIT 环境中与其他应用程序进行测试时发现一些问题，并且必须再次返工。我不认为开发人员会等到其他版本完成，然后在部署到 NP、Srtagign 和 SIT 等环境后发现问题，然后花时间进行返工，而不是使用正在进行的版本期间的时间在真实环境中进行测试。可以帮助更快地解决问题。

目前的设计为：

我们现在正在对应用程序进行容器化，并寻找在 K8s 中部署多版本的选项。

我正在设计让开发团队可以选择部署多版本并随时测试任何内容，而无需等待环境。这将有助于更快地识别问题。

新设计如下...

我需要帮助

1. 如何为 K8s 中的所有版本的应用程序保留相同的 URL，例如 app1.example.com 和 app2.example.com，同时还传递标头（或 cookie）来识别正确的版本。
2. 假设需要服务网格（ISTIO）来完成基于标头或cookie的多版本路由，我如何维护配置。
3. 我需要涵盖哪些内容，不需要涵盖哪些内容？考虑到开发人员在任何给定时间都不会维护超过 4 个版本。
4. 我忽略了任何设计缺陷或任何可以轻松解决问题的增强功能吗？

谢谢，

Answer 1

我的经验表明，团队永远没有足够的环境来测试应用程序。因此，人们真正想要的是每一层内有许多独立的环境。理想情况下，它们还应该能够轻松地自动或按需扩展、销毁和重新创建。这可以通过使用 K8s 命名空间 和 Helm 等工具来实现，这些工具允许通过一个命令部署整个 K8s 环境。

我需要帮助

我将尝试对所有四个问题给出一般性答案。

我认为多版本路由并不是真正需要的，基于它的解决方案将比它需要的复杂得多。此外，如果它是面向客户端的应用程序，那么第一个、最简单的用例就是像用户一样手动访问应用程序。如果必须在 header 或 cookie 中设置版本，这是不可能的。

如果您在命名空间内将测试作为容器运行（这基本上是 Helm 图表测试的推荐方法），您将自动拥有相同的 URL，因为您在命名空间内运行它们。

如果您不这样做 - 在任何工具或框架级别具有多个配置是很常见的事情。您还可以使用配置管理和自动化工具（如 Ansible 等）集中控制它们。

考虑到开发人员在任何给定时间都不会维护超过 4 个版本

我不会在这里依赖任何具体数字。团队随着时间的推移而成长，他们的需求和他们开发的应用程序的复杂性也在不断成长。