最近项目的心得

    1.  CRM Mobile项目做二期的时候，接口升级。在开发阶段没有考虑太多，直接把一期项目的Web Service调到了最新的版本。

    当时并没有考虑上线的切换问题，如果二期项目做回滚的考虑，就需要Web Service版本能够回滚或者倒退。但现在在开发环境测试的结果是，Web Service没有办法做旧版本恢复。

    这样如果二期项目上线，新版的WSDL文件传输Production环境，万一出现效率问题或者其它原因影响用户使用、用户体验，如果需要倒退到Mobile一期，就会出现Web Service接口不兼容。

    按道理Web Service接口升级，一期的Mobile平台跟着升级，但是现在供应商没有资源做这个事。就需要考虑Web Service提供2套版本支持上线后的2套并行或者上线失败回滚的可能。

      结论是在系统设计和开发阶段就应该考虑上线切换的事情。 

     2.  对于CRM项目，通常主数据有很多工作是需要提前在生产环境处理的，批导入，LSMW或者其它的初始化。批导入程序、MW跟主数据同步相关的增强、主数据的AET字段，这些最好是单独包一个请求号。这个请求号可能在整个项目转产之前，需要提前传输到生产环境。

          如果这些主数据的请求跟其它的开发任务包含在一期，在项目计划到达主数据处理的阶段就会非常麻烦，需要单独封装新的Change Request，而且还要考虑版本问题。 

     3.  项目阶段，同时又有运维的需求改动了项目范围内的报表或增强程序，也会造成转产时的风险。版本错误、系统dump、系统不可用都有可能。

        最好的是项目阶段，拒绝项目范围内的程序同时被运维需求改动。这个往往很难控制。一个是运维的支持人员需要能够识别出来，其次也要说服用户暂缓需求。

        如果发生了运维请求改动的情况，比较好的是，知道请求号已经被项目占用，等前者释放后，重新封装一个请求号。并在运维变更转产的时候格外注意版本号顺序。这个需要Function和BASIS、ABAPer做非常好的沟通和协调。

        最麻烦的是，运维压根不知道项目改了什么东西（可能项目改过的版本已经传输到QAS环境了），运维单就稀里糊涂做完了，最后转产到生产环境。风险是，项目GO-LIVE的时候，就可能会出现版本覆盖了。

        有的时候，一个需求改动的工作量远远比不上传输出错后纠错的工作量。前提是这个错还是非常明显，如果是不明显（不dump）的版本错误，估计要隐藏很久以后才能被发觉。最坏的影响就是造成系统不可用。

         生产环境如果因为请求号传输出错不可用，通常的紧急处理措施，要么从QAS环境把之前的旧版本重新传输一次，覆盖到PRD的新版本。要么就是从DEV重新修正最新的版本，逐步往后传输。

      4.  运维变更请求不能挂太多东西，不能在测试环境停留太长时间。挂太多东西，往往因传输的原因，会阻塞后面其它的需求。在测试环境待太久，反复修改，多次从DEV传输到QAS，潜在的风险是以前挂的某些表或结构，在这个过程中可能被其它的变更请求修改过。当前这个变更单转产到生产环境，可能因为表或结构少字段dump。

      偶尔会出现因为表或结构不在生产环境、结构不匹配而出现dump的情况，那就是这些表是其它并行的运维变更里面新增的，只在开发环境或测试环境有，生产环境并没有。当前这个运维变更先转产，在DEV/QAS都不会发现问题，直到传输PRD才会发现。