update how to publish

Author: kaka89

dev-process/how-to/how-to-publish.md

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