玩转Kubernetes开发测试环境

现在越来越多的研发团队开始完全基于Kubernetes开构建自己的研发基础设施和持续交付过程，Kubernetes原生的一些特性在一定程度上可以帮助开发者解决一些开发过程中的联调问题，但是软件研发根本要解决的是人与人直接的协作问题，本文将围绕云原生下的开发协作和效能提升问题来讨论。

流水线是工程效率的提升的银弹？

说到软件交付效率提升，我们的第一反应一定会是持续集成/持续交付的相关实践。而在CI/CD中最重要的一个关键实践就是建立团队的持续交付流水线。而实践持续交付时，我们基本的目标就是竟可能的自动化所有需要人工参与的流程，通过自动化流水线的方式将代码发布到线上环境。

因此流水线就像是一个万能的框，什么合适都能往里面装。不对不同类型的团队流水线也能被玩出各种不同的花样。通过更多的测试自动化/运维自动化来消除整个发布过程中的风险。通过优化每个流程执行来优化交付等待时间。

发现效率瓶颈

而最终我们会发现，从瀑布-敏捷到持续交付，整个软件交付过程中耗时最多的部分是开发阶段。而在开发阶段，作为程序员，应该大体都是在 “编码 - 单元测试（可选） - 等待 - 集成”的流程里面循环往复，直到代码能够满足预期交付上线。那如果我们能够有有效的减少软件交付团队在 “开发”这个阶段的耗时，那么整个软件的交付效率在已经实施持续交付实践的基础上又能往前迈出巨大的一步。这也是我们为什么会开始关注“开发阶段”效能的最重要原因。

而在实际的工作场景下，我们会发现在某些情况下，持续交付流水线虽然能一定程度上解决自动化的问题。但是对于开发人员来说其实并不友好。其中最关键的问题就是日常测试环境的稳定性。一般来说，我们希望开发人员能够频繁的提交代码，通过构建测试，并部署到日常测试环境已触发一些验收测试用例，以及方便开发人员自测。而这个模式除非整个团队只有一个人的情况以外，只要涉及到多人协作就会产生巨大的问题。这里列举了一些典型的问题，例如：

• 越来越长的等待时间和反馈周期：一次提交，集成1小时

• 测试环境发布频率高，稳定性极差（测试环境抢占，Debug测试）

• 多套环境维护成本巨大

流水线的副作用与应对