add how to publish

Author: umasuo

how-to-publish.md

@@ -0,0 +1,52 @@
+# 如何发布我们的软件
+目前在我们的系统中，我们的软件产品总共有3中类型：App，Web，后台服务，三种类型各不相同，发布的方式和流程也会有一定的区别，每种类型，按照具体的流程去发布。 
+
+有几个都需要注意的点：
+- 所有发布，必须由测试人员完成测试，产品完成验收方可发布
+- 所有发布，必须提供回滚的操作流程
+- 所有发布，在发布后的短时间内，需盯紧系统的Dashboard, 如有异常及时排查、回滚
+- 所有发布，需知会刘权；重大更改，需知会陈良均、刘颖，并提供简介
+- 如果涉及到了客户、市场、财务、一线的操作，需提前知会他们并提供相关文档，如果有问题，可延迟发布
+
+# App的发布
+App的发布有以下一些特点:
+- 发布渠道多样：Android只能通过各种安卓渠道进行发布，iOS则只能通过官方渠道进行发布
+- 渠道要求不通：不通的发布渠道，对App的要求、发布素材的要求，以及相关文件的要求各不相同
+- 不可逆：版本一旦发布出去，旧版本就被替换掉了，不能够同时存在多个版本，也不能够回退到某个版本。
+- 响应慢：如果版本发布出去，发现问题很多，那么只能够通过再次发布新版本来解决，而这整个的发布、审核的过程比较慢
+- 客户直接体验
+
+基于以上特点，约定App的发布流程如下：
+1. 测试必须完成测试，产品必须完成验收
+2. 产品准备发布文档、素材、以及版本介绍（尤其是比较重要的新功能）
+3. 重大改动时：写钉钉审批，发送刘权、陈良均，抄送刘颖。钉钉内容需包含：版本号，主要改动，测试方法和结果，发布渠道，预定发布日期，测试体验帐号，安装测试说明文档。
+4. 如果涉及到了市场部、财务、一线等部门的业务改动，需提前告知，并提供操作文档（如果需要），并组织会议进行培训（如果需要），需要让他们明确知道我们发行的版本对其工作造成的影响。由他们再跟进具体的客户进行培训。
+5. 审批通过、相关人员知会完成，可提交到渠道审核
+6. 渠道审核完毕（通过、不通过），需提供审核结果到研发群，研发部的同时，尽量自测一下
+7. App上线后，观察2天，及时手机客户反馈、一线问题反馈等，如果有重大bug，及时用旧版本提交回退
+
+# Web网站的发布
+Web网站的所有更改控制权都在自己手上，所以发布的时候可控度比较高，但其和App有个共同点，就是客户会直接体验到更改的内容。总体说Web的特点如下：
+- 发布渠道唯一，且可控
+- 用户直接体验、如果是后台系统的前端发布，那么则会直接影响到一线操作人员的使用
+
+基于以上特点，约定Web端的发布流程如下：
+1. 测试必须完成测试，产品必须完成验收
+2. 如果是涉及到比较大的改动（新功能、严重bugfix、功能改动），需要提供版本介绍
+3. 重大改动时：写钉钉审批，发送刘权、陈良均，抄送刘颖。钉钉内容需包含：版本号，主要改动，测试方法和结果，预定发布日期，测试体验帐号
+4. 如果涉及到了市场部、财务、一线等部门的业务改动，需提前告知，并提供操作文档（如果需要），并组织会议进行培训（如果需要），需要让他们明确知道我们发行的版本对其工作造成的影响。由他们再跟进具体的客户进行培训
+5. 审批通过、相关人员知会完成，可通过灰度发布的方式进行发布
+6. 逐步发布完之后，产品经理需实时跟进项目报表和问题反馈，如有异常，及时回滚
+
+# 后台服务的发布
+后台服务的特点：
+- 可控性高：所有控制权全部在开发者手上
+- 影响大：影响所有渠道的客户
+- 无界面：用户几乎不会直接体验到后台的改动
+
+基于以上特点，约定服务的发布流程如下：
+1. 测试必须完成测试，产品必须完成验收
+2. 开发人员完成`update.md`的编写，格式与内容参照ops文档
+3. 如果需要进行数据库、数据格式等的改动，开发人员需提供改动的SQL，并在测试环境中测试
+4. 如果涉及到了市场部、财务、一线等部门的业务改动，需提前告知，并提供操作文档（如果需要），并组织会议进行培训（如果需要），需要让他们明确知道我们发行的版本对其工作造成的影响。由他们再跟进具体的客户进行培训
+5. 灰度发布，逐步完成系统的发布，发布过程中以及发布后，需及时更近系统报表，如有异常，及时回滚