这是一个创建于 821 天前的主题，其中的信息可能已经有所发展或是发生改变。
“下午 2-3 点我需要占用测试环境联调项目，大家不要发布喔！”
看到群里的消息我内心一阵苦恼，由于公司使用的是微服务架构并将其部署在了 Kubernetes 集群上，因此团队负责开发的服务是整个微服务架构其中的一环，整个系统的正常运行需要依赖微服务系统中的上下游服务，这导致每每到了发新版本的窗口期，大家都开始占用测试环境联调测试自己开发的功能，导致排队使用测试环境的情况。
今天是发版日，我也需要将自己的功能发布至测试环境验证功能是否正确，有人占用测试环境的话会导致我无法随意测试与修复功能，排队使用测试环境会影响我的发布效率，到时候又要被产品经理吐槽上线慢了:(
“那我安排在 3-4 点” 团队里另一名工程师在群里说。
看到测试环境的使用时间不断被挤压，我也顾不上是否需真要用一个小时，赶紧在群里喊“我预期 5 点开 PR 合并代码，所以 4-5 点我要测试一下，用好了会通知大家。”
想必各位使用微服务架构的同仁和我有一样的困扰，那就是“集成测试联调真的太他丫讨厌了！”，尤其一到发新版本的窗口期，测试环境简直犹如网红餐厅，大排长龙，各个功能都要测，只能乖乖等。很多公司和我在的这家企业一样，只有一套测试环境，一到发版前各个项目时间都很紧，全挤一起。尤其现在敏捷开发迭代周期越来越短，测试也越来越频繁，测试环境着实是不够用啊。
于是我去找了找目前有没有能解决这个问题的方案，发现有一些工具链可以解决这个排队耗时问题，比如 TeamCode( https://www.teamcode.com)新推出的微服务集成测试工具 KubeOrbit( https://www.kubeorbit.io)，帮助团队高效测试微服务。
我打开他发来的产品文档，发现此工具允许我在公司测试环境的 Kubernetes 集群中定义基准环境：
$ kubectl label deployment your-deployment version=base
我还可以基于基准环境创建不同的测试通道，比如测试环境 1 和测试环境 2：
# Create a test env with name v1
$ kubectl label deployment your-deployment-v1 version=v1
# Create a test env with name v2
$ kubectl label deployment your-deployment-v1 version=v2
将自己的服务加入目标测试环境
apiVersion: network.kubeorbit.io/v1alpha1
kind: ServiceRoute
metadata:
name: serviceroute-sample
namespace: sample-namespace
spec:
name: pod-svc
# Add your service to the test env named with v1 by defining trafficRoutes
trafficRoutes:
routes:
- name: v1
labels:
version: v1
headers:
version:
exact: v1
default:
version: base
部署到目标测试环境中
kubectl apply -f /path/to/your/serviceroute.yaml
使用体验总结
KubeOrbit 工具主要有如下三种功能：在微服务测试环境内创建测试通道，这样就可以获得一个单独稳定的集成测试环境；把需要测试的微服务添加至测试通道中，将它们与其他不同版本的微服务隔离开来；在发起微服务请求的时候指定测试通道，KubeOrbit 会将其转发至你所指定的测试通道。这些功能刚好解决了我和团队耗时排队测试的困境，满足了团队测试的需求：
1. 团队内部并行开发与联调测试的需求，大家无需再争抢使用测试环境
2. 按时交付项目的需求，避免了因为测试环境不够导致项目延期的情况
无需调整已有的技术栈和架构，KubeOrbit 会适配现有的微服务，还能够隔离不同测试通道之间的通讯。但是在产品的使用过程中，我发现还需要有较多的人工操作，增加了这个工具的使用门槛。如果能够把这些流程自动化，会给用户体验带来较大幅度的提升。刚好从公众号得知产品在 GitHub （ https://github.com/teamcode-inc/kubeorbit ）全部开源的消息，我也打算好好研究一下，持续关注这个项目和平台，希望未来有更好的体验。
看到群里的消息我内心一阵苦恼，由于公司使用的是微服务架构并将其部署在了 Kubernetes 集群上，因此团队负责开发的服务是整个微服务架构其中的一环，整个系统的正常运行需要依赖微服务系统中的上下游服务，这导致每每到了发新版本的窗口期，大家都开始占用测试环境联调测试自己开发的功能，导致排队使用测试环境的情况。
今天是发版日，我也需要将自己的功能发布至测试环境验证功能是否正确，有人占用测试环境的话会导致我无法随意测试与修复功能，排队使用测试环境会影响我的发布效率，到时候又要被产品经理吐槽上线慢了:(
“那我安排在 3-4 点” 团队里另一名工程师在群里说。
看到测试环境的使用时间不断被挤压，我也顾不上是否需真要用一个小时，赶紧在群里喊“我预期 5 点开 PR 合并代码，所以 4-5 点我要测试一下，用好了会通知大家。”
想必各位使用微服务架构的同仁和我有一样的困扰，那就是“集成测试联调真的太他丫讨厌了！”，尤其一到发新版本的窗口期，测试环境简直犹如网红餐厅，大排长龙，各个功能都要测，只能乖乖等。很多公司和我在的这家企业一样，只有一套测试环境，一到发版前各个项目时间都很紧，全挤一起。尤其现在敏捷开发迭代周期越来越短，测试也越来越频繁，测试环境着实是不够用啊。
于是我去找了找目前有没有能解决这个问题的方案，发现有一些工具链可以解决这个排队耗时问题，比如 TeamCode( https://www.teamcode.com)新推出的微服务集成测试工具 KubeOrbit( https://www.kubeorbit.io)，帮助团队高效测试微服务。
我打开他发来的产品文档，发现此工具允许我在公司测试环境的 Kubernetes 集群中定义基准环境：
$ kubectl label deployment your-deployment version=base
我还可以基于基准环境创建不同的测试通道，比如测试环境 1 和测试环境 2：
# Create a test env with name v1
$ kubectl label deployment your-deployment-v1 version=v1
# Create a test env with name v2
$ kubectl label deployment your-deployment-v1 version=v2
将自己的服务加入目标测试环境
apiVersion: network.kubeorbit.io/v1alpha1
kind: ServiceRoute
metadata:
name: serviceroute-sample
namespace: sample-namespace
spec:
name: pod-svc
# Add your service to the test env named with v1 by defining trafficRoutes
trafficRoutes:
routes:
- name: v1
labels:
version: v1
headers:
version:
exact: v1
default:
version: base
部署到目标测试环境中
kubectl apply -f /path/to/your/serviceroute.yaml
使用体验总结
KubeOrbit 工具主要有如下三种功能：在微服务测试环境内创建测试通道，这样就可以获得一个单独稳定的集成测试环境；把需要测试的微服务添加至测试通道中，将它们与其他不同版本的微服务隔离开来；在发起微服务请求的时候指定测试通道，KubeOrbit 会将其转发至你所指定的测试通道。这些功能刚好解决了我和团队耗时排队测试的困境，满足了团队测试的需求：
1. 团队内部并行开发与联调测试的需求，大家无需再争抢使用测试环境
2. 按时交付项目的需求，避免了因为测试环境不够导致项目延期的情况
无需调整已有的技术栈和架构，KubeOrbit 会适配现有的微服务，还能够隔离不同测试通道之间的通讯。但是在产品的使用过程中，我发现还需要有较多的人工操作，增加了这个工具的使用门槛。如果能够把这些流程自动化，会给用户体验带来较大幅度的提升。刚好从公众号得知产品在 GitHub （ https://github.com/teamcode-inc/kubeorbit ）全部开源的消息，我也打算好好研究一下，持续关注这个项目和平台，希望未来有更好的体验。
Select Language