先来一波场景：团队A忙忙碌碌终于把这个sprint的story做完了（我们玩的是敏捷开发），给po（产品负责人，接下来篇幅会以po来表示）演示完了，po给客户演示也ok了。po发来好消息，跟我们说可以上生产了。团队B还在为处于sprint的周期中，苦苦挣扎。我们内心也是满怀喜悦，心想：“你看那群人还在苦苦挣扎”。终于到了下班时间了，团队A对这次上线已经万事俱备了。就差东风了。团队A的leader对A队员说，麻烦deploy一下服务A；服务A部署完毕，没有任何问题。啪啦啪啦，服务A、B、C、D都部署好了。到最后发现，天啊，服务E涵盖了团队B的不完整的功能（团队B的功能还没做完，也没有测试过）。好了，此时的你，我相信你会“吐血”，吐完血还是乖乖把服务A、B、C、D回滚回来。然后打电话跟po说，上线失败了。
我相信在多团队协作的时候，总是会遇到上线不同步，代码被覆盖，功能不见了，等等这些让痛心疾首的情况。那么该如何避免上述的情况呢？我们来一层一层抛开问题的本质。问题：为什么团队A上线，需要等待团队B？因为大家的sprint的周期不一致，ok，这个我们没办法避免，因为每个团队负责的功能大小不一致，po也不一样，所以在时间上无法同步。那么我们只需要做到团队A上线不需要等待团队B就好了。那么会有人问，如何做到不等待？团队A做完功能需要合并到develop环境（集成测试环境，接下来篇幅会以develop环境来表示），然后合并到uat环境（预发布环境，接下来篇幅会以uat环境来表示）给用户演示。团队B也一样，也需要做同样的动作。那又会有人提出建议，团队A把功能上到uat环境，然后给客户演示，客户ok了，团队A就把功能上线，接下来就轮到团队B，上到uat环境给客户演示团队负责的功能，ok了，然后上线，这样就不会冲突了。这个也算是一种方案。但是这个方案需要天时地利人和齐聚才能得以实现，因为在现实情况下，给po演示完，po给客户演示这往往需要等待一段漫长的过程，甚至给客户演示完，客户也会得到“启发”，给你来个“我需要根据手机壳的颜色改变屏幕的颜色”的需求。这个时候，你可能还需要几天时间去修改功能。整个过程下来可能需要一个星期。也就是说团队B需要等待团队A用完这个坑才能用，效率极低。
上面讲到一种方案，我想大家不会采用。那是否还有更好的方案吗？当然有，不然我早死了。“发布火车”，什么是发布火车呢？从字面上来理解，就是像火车一样，定时就会载货走，不会等任何人。说好的定时，那什么为开始时刻呢？在你的代码推向develop环境那一刻开始，“火车”就开始启动了，也就是只要你的代码部署到develop环境，就说明你的功能是完整的、可用的、是可以上线的。这样约束会有什么好处呢？限制其他团队把不完整或者残缺的功能推向develop，影响可以上线的功能。也就是说团队A开发好功能了，团队向po演示完，po接收，我们把功能部署到uat环境，po向客户演示完，决定可以上线，是不会携带不完整或者残缺的功能的。但是也有可能会携带其他团队的功能，但是携带的功能起码是完整的，可用的。这样也不至于影响到团队A的上线了。这个约束可以解决上述案例中的一个痛点：团队A上线时发现有团队B不完整的功能。
肯定有人问，那测试人员在哪里测试？如何保证部署到develop环境的功能是完整的？团队向po演示是用什么环境演示？同时也会出现团队A携带了团队B的完整功能，但是团队B的功能客户那边还没确认可以上线，就把团队B的功能带上生产了，等等问题。我来一个一个解释我们是如何做的。
网友评论