相关的系统的更新带来的环境问题

本文尝试叙述一个在开发中真实遇到的问题，希望读者能参与讨论并最终得出一个解决之道。

一个电商网站的两个子站，分别由不同团队负责，它们是 ECommerce Portal 电商网站，以及 Management Portal 运营管理网站。针对一组相关功能，出于商务上的需要，Management 的开发进度与 ECommerce 通常并不一致。

对于 ECommerce 不直接负责开发的服务、或者网站，他们通常会在本地机器中使用其他团队提供的脚本部署一套“编译”版本 M 供使用，而针对自己直接负责开发的服务，由于需要时常更新、预览效果，则使用源码版本 e 直接运行、调试。相反地，Management 团队在本地需要 Ecommerce 时也使用编译好、用于发布的 E，而一般不需要使用源码版本 e。

现在，ECommerce 需要增加一项功能，即展示一件商品最近购买的人的名单。团队需要确保在功能开发完成时，其结果要与 Management 已经实现的功能一致。在 Management 里，展示这个名单的功能在一周之前已经完成。

此时，ECommerce 团队在开发之前，需要更新本地用于日常预览用的编译版本 Management 网站 M。然后，接着 ECommerce 团队发现自己已经超过两周没有更新本地的 M 了。

噩梦开始！

ECommerce 团队尝试打开 M 的 URL，页面报错：

? 问题：在类 xyz 里没有 doSomething 方法
* 原因：Management 现在需要依赖新版本的运行时
> 解决：ECommerce 团队升级了本地的运行时版本
: 时间：30 分钟
x 风险：大

ECommerce 团队尝试打开 M 的 URL，页面报错：

? 问题：在 xx 表里缺少 abcd 列
* 原因：Management 更改了他们的数据库结构（Schema）
> 解决：ECommerce 团队使用 WiKi 里介绍的方法做了数据库迁移
: 时间：5 分钟
x 风险：小

ECommerce 团队尝试打开 M 的 URL，页面报错：

? 问题：缺少配置项 abc
* 原因：Management 增加了一个必要的配置项，需要手动配置，但相关文档还没有来得及更新
> 解决：ECommerce 团队尝试查找 WiKi，但没有找到，只好去到另一个楼层找到 Management 团队最终解决
: 时间：1 小时
x 风险：无

在 2 小时之后，E 团队终于成功地再次打开了 M 系统，然后准备继续工作。这还不是个案。有时候不太幸运的话，还可能遇到更多问题。比如 M 的部署脚本在本机无法正常工作，页面报错信息不够明确无法及时发现或知晓发生了什么错误等。

在实际开发实践中，尤其当系统间的依赖关系变得更复杂，业务形态更多样，上述 E 团队面临的系列问题的复杂度，以及相应的成本，将会随着多个因素的变化而正相关地增长：

* M 的开发越活跃
* M 依赖的其他服务或网站越多
* M 业务与 E 业务越不相关
* M 团队与 E 团队的沟通越不及时流畅

此类问题隔一段时间就会发生一次，尤其对那些刚加入 E 团队的对各方面不够熟悉的成员来说，更是一个巨大的打击。

不知各位有否在实践中遇到此类问题，有何解决方法，欢迎探讨。