我这几年做DevOps评估，经常因为开发人员没有进行充分的端到端的自测而给参评项目扣分。然而这经常并不（全）是开发人员的思想意识问题或者习惯问题，经常是开发人员的工作环境有问题：他方便做端到端的自测吗？或者积极一点，这么描述：如果我们想给开发人员提供一个理想的端到端的自测联调的环境，那这样的环境应该长什么样？
场景难度：一级
先看简单的情况。如果这个软件的规模相当小，源代码就一个不大的Git库，相应生成一个安装包/容器，那这事儿就特好办。开发人员本地开发环境就够用了。debug也方便，设断点，看数据，都是IDE自带的功能。
场景难度：二级
如果软件的规模大一些，复杂一点，那就开始有麻烦了。比如，分了前后端。开发一个新feature（比如一个用户故事/一个线上缺陷修复/一个不大技术改造等等），既涉及到前端，也涉及到后端，那按理说要一起联调，联调通过了才能送测。那在哪儿联调？
一个常见的，可接受的，但不够好的做法是，等把后端代码改动提交到后端代码库的集成分支、前端代码改动提交到前端代码库的集成分支后，往一个自测联调环境（经常叫开发环境或者集成环境）里部署，然后在那儿测在那儿调。
但这样一来，代码改动就得经过git push进而流水线构建部署后，才能开始联调。甚至，需要通过合并请求/拉取请求（Merge Request / Pull Request）把feature分支合入集成分支后，才能开始联调。这就有点麻烦了。
而更大的不方便是，没法使用IDE的debug功能了。就算你使用IDE的远程debug功能，连接到自测联调环境里，你敢设断点吗？这个自测联调环境可是公用的，说不定有别的小伙伴也在测别的feature。你这一断，别人就没法测了。
另一个常见的，可接受的，但不够好的做法是，前后端的开发人员，分别在自己的本地环境中启动前端和后端，然后两者连接，联调看效果。这样debug就没问题了。也不需要流水线甚至合并请求了。但是会有另外一个问题：联调的时候，得占着两个本地环境，两个人都得停下来联调，谁也干不了别的了。
相对来说，在其中一人的本地环境里，把前后端都跑起来联调，是个还不错的办法。
场景难度：3级
然而随着软件规模的扩大和复杂性的提高，这个办法也会变得不好用。本地跑前后端两个微服务还凑合，那要是更多的微服务呢？且不说部署起来麻烦，本地资源比如内存可能都不够用了。
那怎么办？还是得在服务器端搞个自测联调环境。但是这个环境必须是专属的，这个特性独占的，只供这个特性的自测联调用，于是可以随时设断点debug。
你能不能做到，开发人员只需要“点个按钮”，就获得一套这样的自测联调环境？
另外，流程也要尽量短。不应该经过合并请求/拉取请求，不需要把feature分支合入集成分支，应该feature分支上的代码直接就部署到这个环境。
甚至考虑，把本地环境“嵌入”这个自测联调环境里。这样，连git push和流水线都省了。debug也更方便。
场景难度：四级
以上，是不是就一劳永逸地解决问题了呢？还没有。当软件更大更复杂的时候，这招也会失效。比如，电商系统经常是几百几千个微服务构成的。那为每一个新feature，都搞一套独立的自测联调环境？那这真玩儿不起啊，哪个爸爸也玩儿不起啊。
当然你可以自测联调不做端到端的。当然你可以在公共的一个自测联调环境里靠日志排查问题。这些你都可以解释成“不得已”、“现实一点”，但是我们现在谈理想，理想中的解法应该是什么样？
那就是虚拟独占方式：你觉得你独占着这个环境中的几百几千个微服务，它们只供你使用，可实际上，它们中的绝大多数，也支撑着其他环境。只有那一两个为你的新feature有改动的微服务，使用的是特定的版本，于是部署了相应的单独的微服务实例。见下图。

怎么实现这样的虚拟独占方式呢？如果你修改的微服务是API调用的调用链的发起者，那简单。把这个微服务在本地开发环境（或服务器端的一个“小”环境，下同）中启起来，让它去调用公共测试环境中的其他微服务就好了。而如果这个微服务的上面还有一两个微服务，那也还好，把它们都在你的本地环境中启起来。
真正难的是，当你修改的微服务位于调用链中间，上面有一堆微服务的时候。这时候就要拼技术了。简单地说，让调用链最顶端的那个微服务开始调用的时候，就在发起的调用请求中夹带上一个信息，这是属于某某特性的那个专属环境的。于是，等调用到你为这个特性修改的微服务时，自动路由到你本地环境中的那个微服务实例。
这篇文章已经写得太长了。总之就是这么个意思，如果你想让开发人员充分地端到端地自测联调再送测，那就应当为他们提供一个足够方便足够好的自测联调环境。当然这里面有很多细节，细节就看《高质效交付》这本书吧。

▊《高质效交付：软件集成、测试与发布精进之道》
董越 等 著
各界领军人物荟萃核心实践研究成果
打破提质降本增效不可能三角
完美契合数字化转型时代企业刚需
一本有趣的图解书浓缩十几个概念几千页内容

《高质效交付：软件集成、测试与发布精进之道》介绍在保证一定发布质量的前提下，如何加速软件交付过程，让它尽量快一点儿，同时让我们投入的精力尽量少一点儿。也就是说，本书介绍如何让软件交付变得更高效。