做大项目，一定会涉及到上下游依赖，上线的顺序就尤为重要。一般来说，无非有以下两种
- 下游先上线，此版本需要兼容上游旧版本。然后上游就可以放松的上线。
- 上游先上线。此种做法要求下游旧版本需要能支持上游新版本。然后下游的新版本需要考虑新版本数据（某些情况下，亦需要考虑旧版本数据）。
第一种做法，好处就是几乎可以应对所有情况。因为我们在做项目时可能都无法预期未来的变化的，让下游来做旧版本兼容，可以应对所有情况。不好的地方就是下游代码恶心。
第二种做法，好处就是下游和上游代码均是相对clean的。但是，它需要上下游在做设计的时候均要考虑到未来的设计，换句话说，就是上游上线什么的，下游不会出问题。
我们需要注意到，为什么这里说是相对的而不是绝对的clean? 上游上线后，一般来说，接口数据将是新数据格式。但是在某些特殊情况下，会出现新旧数据交融的情况。这时下游在上线时就需要以“支持新数据，同时兼容旧数据“为准则。支持新数据是代码核心重点，兼容旧数据是处理边界情况。在这种特殊情况下，下游代码较为“恶心“，和第一种做法一样，但是这也是无法避免的。
第一种方法风险小点；第二种风险大些，需要做较多回归性测试，保证下游可以hold住上游的变化。
具体选择哪种办法，还是要看项目而定。我个人是比较推荐第二种做法，因为这样可以保证代码的相对clean。当然，这对接口的设计就会有些特殊的要求，比如，接口尽量以增量的方式来完成，下游在读取字段时以尽量小的范围方式来读取。
遇到新旧数据交融的情况下，谁先上线都无法避免代码恶心的问题。但是我还是推荐第二种做法。我们写代码时均需要保证自己心里有“面向未来开放”的设计原则。因此好的设计是，上游上线新功能，下游可以做到兼容。
以我在百度多年经验为例，上线新系统比升级旧系统容易很多。在较大规模的平台上线中，新旧数据”交融“的情况均为常见情况。下游的设计则需要多担当责任。
如果出现上游升级2.0之类更新非常之大，新旧数据非常复杂，差异非常之大的情况下（例如DAN1.0的升级），也可以考虑的一种做法是，上游新旧系统同时运行，新系统采用新数据格式，旧系统采用旧数据格式。在上游上线新系统后（此时上游旧系统亦同时在运行，下游亦在运行），下游上线，对接上游新系统，这时接口数据均是fresh的，不需要考虑新旧数据的兼容性。下游在上线过程中，要随时准备切换回上游旧系统数据接口。这种上线模式，风险非常之大，但是也只有这样，才能保持，上线新系统的过程中，整个服务平台不会断流。