生态产品开发流程及迭代规范

一、选型流程

• 目前采用YonBuilder-应用构建进行开发，YonBuilder目前有两个版本：标准版、专业版。

  • 标准版不需要资源，即在公有云上即可完成功能开发，开发的过程相对简单易用，不需要太复杂的计算、采用标准的页面进行开发。

  • 专业版需要独立的资源，需要进行前端、后端、移动端功能代码开发，可以实现复杂的运算，进行复杂定制化页面开发。

二、选型后模块购买

• 标准版需要购买：
  • 可视化应用构建：必选。开发自建档案、自建单据（含业务流、工作流）时，必须要购买“可视化应用构建”。默认带10个开发用户许可，支持增购。
  • 沙箱环境：必选。需要购买开发沙箱、测试沙箱。开发沙箱用于开发用，开发完成后迁移到测试沙箱进行验证。
  • 可视化应用扩展：可选。要在原厂平台或领域的档案或单据页面增加控制逻辑、按钮、扩展字段时需要购买“可视化应用扩展”。控制特性，不控制许可。
  • 报表平台：可选。计量单位：报表数。如果开发需求中需要开发报表，还需要购买报表平台或智能分析。
  • 智能分析：可选。计量单位：注册用户数。智能分析与报表平台的关系：报表平台是智能分析功能的子集。报表平台、智能分析的使用场景、许可控制方式差异较大。报表平台按开发的报表数计费，智能分析按使用报表的用户数计费。如果采用应用构建平台做开发，要配置数据源，需要购买智能分析开发报表。
• 专业版需要购买（标准版基本上）：
  • 应用构建平台：必选。开发带有复杂运算逻辑、定时计算服务、非标准页面、大数据量应用的场景下，需要购买“应用构建平台”。默认带10个开发用户许可，支持增购。
  • PaaS资源包：必选。用于CPU、内存、数据库存储空间的扩展，支持三种规格，根据需要选购及报价。详细内容参考：环境准备
  • 文件存储：可选。是指部署代码服务的服务器的磁盘空间，购买PaaS资源包默认含150G磁盘空间，如果磁盘空间不足时，可增购文件存储，为磁盘空间扩容。
  • 数据存储：可选。是指通过客开功能录入或采集的数据的存储空间，即数据库的存储空间。购买PaaS资源包默认含150G磁盘空间，如果磁盘空间不足时，可增购数据存储，为数据库扩容。

三、需求开发测试流程

• 参与人员角色：产品、开发、测试。
• 不同角色的职责：
  • 产品：负责针对ISV生态产品进行需求梳理，形成产品需求文档后进行评审。
  • 开发：针对已经产生的需求文档进行分析，整理形成后的开发文档，然后进行开发计划编码，完成后，按开发计划进行开发代码。将开发的成果在开发沙箱进行单元验证，无问题后可以迁移测试沙箱。BUG紧急修复的问题，需要在在JIRA中记录缺陷，然后在修复版本上加"HOTFIX-YYYYMMDD", YYYYMMDD为年月日，如: HOTFIX-20230216; 非紧急的BUG的JIRA问题在修复版本只为8位年月日。
  • 测试：针对已经开发出来的生态产品梳理一些测试用例，然后根据用例去进行测试，测试的问题将提问题到JIRA，然后由开发人员进行问题调整，调整后将问题进行关闭。测试的问题有问题的话需要在JIRA中提“缺陷”工单。
  • 支持问题：到JIRA的支持问题，如果后续迭代的话，需要复制此JIRA，移动到“迭代计划”类型中，然后进行周期迭代上线。如果能尽快解决的话，和客户沟通后，直接选择到“处理完成”。

四、迭代需求开发过程

• 场景：当生态产品开发完成后，需要新做功能需求，此时需要按一个规范流程。
• 实现过程：
  • 此时有新需求的时候，需要先将需求创建JIRA故事，记录好JIRA的“影响版本”，然后进行排期开发。
  • 完成后需要将开发的功能放到测试环境进行验证，同时JIRA也要同步调整状态。
  • 验证出现问题后，需要将问题再次登记到JIRA缺陷。
  • 无问题后再同步到生产环境、客户环境。

五、升级的过程

• 场景：当现阶段还有开发功能，生产上还有BUG要修改，需要将改好的BUG升级到生产环境中。

  ​ 开发完成后，需要将修改的BUG进行合并，然后发版到生产环境

• 环境准备（A类-简单）：开发沙箱（用于开发应用）、测试沙箱（用于验证开发的应用）

  当发版较多的情况下需要准备4个沙箱（B类-复杂）: 迭代较少的准备以上2个沙箱即可，根据情况准备。${产品名}-DEV-开发 ,${产品名}-DEV-测试,${产品名}-RELEASE-开发，${产品名}-RELEASE-测试, 如：GSP-DEV-开发。

• 应用构建部分（BUG修改流程）：

  • 如果发现生产上有BUG，需要进行修改函数、后端服务，这个时候需要在 ${产品名}-RELEASE-开发 沙箱进行调整，验证无问题后同步到 ${产品名}-RELEASE-测试 进行验证，无问题后再发布到生产。
  • 涉及业务流、字段、按钮的bug修改的时候，需要从 ${产品名}-DEV-开发 修改，然后再发到 ${产品名}-RELEASE-开发 环境，再修改后再到 ${产品名}-RELEASE-测试 环境验证，然后再发到生产环境。
  • 需求和BUG修改合并流程：当开发完成后，BUG也修改完成后，将 ${产品名}-RELAESE-开发 做的新功能，手工修改合并到 ${产品名}-DEV-开发，然后进行单元测试，完成后再合并到 ${产品名}-DEV-测试 进行验证，通过后再发到客户的生产环境，然后再同步到${产品名}-RELEASE-开发 ，${产品名}-RELEASE-测试 环境。

• 代码部分：

  • 开发部分的代码分支需要为develop, 生产上的分支为master。
  • 当需要升级的时候需要需要在master分支上复制一个分支，命名为hotfix_${feature}, ${feature}为要修改BUG的动态简写。
  • 修改完成后将这个分支发布后，在【测试沙箱】进行验证，无问题后将该分支全并到master中，进行上线。

六、升级的流程图