背景：最近一直在公司做系统升级，这是一个用了好多年的系统，数据库的设计已经不能满足日益增长的访问量，数据库结构调整势在必行的阶段。也就是说从底层上的架构已经发生了变化，系统复杂度比较大。我在想怎样才能更好的开发出相对健康的系统，并为以后阶段的迭代创造一个相对规范的平台的。我之前所在公司是一个国际性的大公司，恰好我也是web产品部门的一个成员，比较来说，我觉得构建一套开发测试与发布的环境，会降低风险，更易取得成功。
风险：
- 数据表变化后带来的数据一致性风险，这次更新的是系统核心表，数据都很关键
- 开发模式成熟度与沟通顺畅的风险
- 未来升级系统的复杂度是否还会重复
- 多系统交互带来的风险
方式1：
团队：项目经理，产品经理，发行经理，测试经理，开发，测试
开发模型：MSF敏捷开发
系统环境：INT cluster,BVT cluster,Product cluster
需求：新版本需求与确认（产品经理与用户沟通）
设计：分析需求，架构是否更新，Spec，DEV Spec，Test spec，项目时间表，WBS(项目经理负责项目时间，产品经理发布Spec，DEV和Test基于产品经理发布的Spec，做相应的开发详细设计和测试详细设计，这一阶段产品经理的spec是唯一的标准，任何有异议的部分都要回到spec中确认，若有问题，更新spec，同时更新dev spec和test spec。项目经理根据项目情况，进行迭代阶段划分，确定每一阶段的提交物。
开发：开发人员基于INT 集群进行开发，对于web系统来说，是离线开发，每周有一次周报，代码review,每日构建
测试：
粗略的分
开发阶段测试：针对每一个新的build进行一轮测试，（自动化，ad hoc）
。。。。。。
MSF敏捷开发模式的具体介绍这里就不再详细介绍了。
优点：
这种方式的每次迭代的基本过程是重复这样一个过程，基于int环境开发，测试，当本阶段功能开发完毕后，测试进行大量测试，开发fix bug，有些疑议问题推迟下一期。测试基本完毕后，移植到BVT环境，再进行测试,然后再把本阶段开发后的产品发布到线上。当N个阶段完成后，在线系统的功能也进一步丰富至完成。
缺点：
- 集群构建比较大
- 测试数据与实际数据分离，所以要求测试人员对spec很熟悉并要具有一定的水平能构建自动化测试，来完成繁琐的数据，场景模拟
- 离线开发状态，对测试要求很高
方式2：
团队：架构师，产品，后台，前台，测试，实际用户
开发模型：阶段开发
系统环境：在线服务器，开发服务器
需求：产品与用户
设计：spec，界面，日期，任务分工
开发阶段：开发人员根据需求，完成代码。
测试阶段：测试启动在本阶段开发人原完全完成时，（此时参与测试的有测试人员+实际用户）
系统升级时，部署一套新系统，用于开发，测试。与在线系统通过撰写服务程序进行数据初始化，即测试系统也是真实数据。开发完成后，给用户权限，进行新测试，并行跑2个系统，当功能完善后，再初始化同步一遍数据，然后完全切换到新系统。
优点：
由于一直在线上开发，所以过度平滑，对测试人员要求不是很高，因为最终用户最熟悉业务
缺点：
线上开发，开发测试比较混乱，可能会影响在线系统的数据正确性
每次系统升级，都需要重新写大量服务程序进行数据同步，开发模型不明确
由于不是一个项目团队，多部门人员沟通上需花费很多精力会略大
个人觉得，新版本的开发依然在线方式，虽然避免了从离线到上线的过程带来的一些风险，降低了一些初期的平台搭建成本。但是，也增加了系统开发复杂度，人员关联，数据正确性等的复杂度，对于项目的控制也会很难。对于我们国内很多公司来说，在学习先进的开发经验的同时，从成本上硬件与软件成本上考虑，怎样更快更高效的构建符合自己所需的一套平台我觉得是技术决策者们需要思考的东西~
结合以前的经验，随想的一篇文章，欢迎大家拍砖，指正。希望根大家学习，一起进步
Terry Dong
