一配云项目版本管理流程
   
文档编号：1pei/IS 2018-0003

修改历史：
   V0.2, 2018.02.XX, XXXX   				  
   V0.1, 2018.01.16, 初稿

1. 简介
   项目、版本迭代式前进，牵引整个公司不断前行。
   
2. 项目任务来源
   用户的每一项功能和需求，可能来源与用户、竞争对手、我们自己分析，都会汇总到产品部门，由产品经理来归纳，总结，分析梳理，安排设计UI，最后形成系统化的需求与概要设计文档。
   这些需求文档还需要经过多轮次的评审，修订，再评审。
   定稿后的需求文档将引领整个公司不断前行。
   通常需要比开发提前1-3个月来安排设计。

3. 版本不断迭代进化
   项目采用版本方式来迭代进化，例如2017.07.01 服务器端版本2.5.0版本上线后，就开启新一轮2.6.0版本的开发。
   通常每个版本的进度如下：2周开发，1周测试周六上线B站，B站运行一周后上线A站，大致一个月一个版本。

   遇到遗留BUG很多的情况下，会安排一个版本专门来清理BUG，这种版本通常整体不超过2周。

4. 项目需求/任务评审机制
   每个模块最重要的两次评审：需求评审+接口评审

4.1 需求评审
    开发+UI+产品经理+测试

4.2 接口评审   
    开发+产品经理

5. 白天项目/晚上BUG开发二重奏
   一方面，项目必须不断前行，开发新的功能，开发与老牌进销存厂家（思锐、怀远等）差异化的功能来满足用户不断增长的新需求。
   另外一方面，源源不断的用户问题类与需求类BUG也需要不断解决。

   为此，基于之前的经验，我们采用白天做项目，晚上解BUG这样两不耽误，两个都快速前行的开发二重奏!
   
   谨记：我们再做5年在进销存方面也无法超越有13年经验的思锐！
         但稳固能够满足绝大多数用户的进销存是我们拓展其他业务的前提！

6. 版本阿里云B站上线倒计时通知
   在B站上线的那一周，从周一开始就要
   "2.X.0版本B站上线倒计时7天"，
   "2.X.0版本B站上线倒计时6天"，
   "2.X.0版本B站上线倒计时5天"，...
   这样，每一天及时发布遗留BUG和项目进展进度, 督促大家在上线前及时处理掉相关问题，确保项目进度正常。

7. BUG上线测试确认流程
   对比较严重的BUG采用分开测试：
   (1) 苏立平先内部测试。
   (2) 典型场景最小集合测试：
       使用100059家的大量产品、库存来实际测试，做一个XS与CG单据导入200条产品来创建单据，保存单据、出库/入库、打印、结算，审核一整套流程。
       每一个步骤都必须要流畅，如果超过2秒以上，就说明出现了严重的性能问题，需要解决完成后才可以上线。 
   (3) 最小集合测试通过后，由张思宇上线到B站，然后雅靖来测试确认；
   (4) B站上线后可能暴露出多个问题，问题解决3天之后再上线到A站。
   这样可以将问题的风险降到最低。

8. 上线升级时间强制要求   
   2018-01-11上午有7分钟左右无法上线: 可能是合并代码出错。
   以后白天不论再怎么样紧急，用户问题白天不再升级，只能在晚上23:00之后升级。