在一个项目上线过程中，会涉及到整个项目团队成员的参与，参与成员及职责分别如下：
1、开发环境由开发人员负责，同时包括了维护与代码版本及版本管理
2、测试环境由测试人员负责，包括了测试时的项目部署、测试、上线申请
3、预发环境由运维（测试）负责
4、生产环境由运维负责
5、所有数据库相关由DBA(数据库管理员)或运维统一负责
已经完成开发的系统或应用正式部署到生产环境前， 要严格按照上线发布的流程进行，基本按照如下的顺序开展。
一、开发提测
开发人员在功能开发完成后首先配置开发环境，将系统部署至开发环境，并在开发环境下完成单元测试、冒烟测试等，没问题了就需要提交一份上线方案。
上线方案必须包含：
- 当前版本所影响的范围
- 新增的功能/内容
- 前后端 版本号
- 前后端负责人
- 代码地址
- 程序部署所需数据库脚本文件
- 项目配置说明清单
- 计划上线时间
- 上线失败的回滚计划等
将上线方案提交技术负责人及项目负责人进行审核，审核通过后邮件提测给测试人员。
二、系统测试环节
在执行之前测试人员是需要根据日常需求评审内容进行测试用例设计的。
- 测试人员接收到提测邮件通知后，开始着手进行测试工作。
- 首先将待测项目从代码地址部署到测试环境，如果需要配置数据库，由DBA或运维配合完成。
- 然后先进行冒烟测试（开发也会做一轮），冒烟测试不通过，以邮件方式打回， 请开发修复完成再次提测。
- 冒烟测试没有问题，就正式进行测试执行，可以开展接口、功能测试、自动化测试等。
- 测试过程中发现缺陷，及时提交缺陷并跟踪开发进行解决，待开发人员修复后进行复测并回归测试。
- 最后，达到测试计划中的准出标准时，总结与分析测试，并输出测试报告。
三、预发环境测试环节
在测试环境中的接口、功能测试等都通过了，并测试结果报告发送相关责任人之后，就可以进入预发布环境的测试了。
1、预发布环境checklist
一般需要测试人员一份checklist，逐一确认每项需要提前准备的资源及环境是否OK，以保证上线前的最后一步的准确性，是很有必要的。
发布策略一般是从下游逐步向上部署，而回滚方案相反，一般是从上游往下回滚。
通用的checklist需要考虑以下几方面：
1）依赖
存储（数据库、分布式缓存）、是否有数据库变更需要代码上线前先提交，并且验证执行成功。
2）动态配置
需要确认代码中的动态配置有无默认值，没有默认值需要先在动态配置系统上添加相关的配置。
3）下游
确认下游jar包版本是否正确，线上最好使用release包、确认下游的业务方是否已经上线。
4）鉴权
验证需要调用的服务都能通过鉴权，检查所有参与上线的子系统都完成授权。
5）上游
- Nginx层，确认路由策略，在发布过程中会不会造成用户不断刷新页面命中不同代码逻辑，给用户带来用户体验上的问题和困扰。
- 上游业务方，确保和上游业务方沟通好，等当前服务全量发布后且观察、验证没问题再通知上游发布。
6）业务内部
- 通过代码review，QA测试等方式保证上线对现有业务逻辑没有影响。
- 代码review：重点查看代码规范、业务逻辑的正确性、对相关功能的影响
2、预发布环境测试
- 预发环境中新功能为最新代码，其他功能代码和生产环境一致
- 预发环境和生产环境的访问域名不同
- 预发布会访问到在线真实数据，尽量不要产生脏数据，从而影响在线环境
- 用户不能访问到预发布环境
- 预发布环境应该尽量避免对线上环境的影响
预发环境测试通过, 则以邮件通知相关开发、产品、运维, 准备正式上线。
四、正式上线环节
1、上线流程
在项目具备发布条件下，正式上线前，开发人员召集所有相关人员(开发,测试、运维、产品)讨论此次部署内容(重点介绍各方的具体内容与职责、 数据脚本执行、部署的顺序、配置文件、 部署时间、回滚方案等)，最后形成会议纪要并发出邮件。
- 确认上线后，测试人员通过邮件发送上线申请，包括上线方案、数据库脚本、配置文件、版本号等，并抄送相关责任人，如开发、运维及DBA等。
- DBA提前执行数据库脚本，应用部署应通过自动化部署平台进行部署，部署系统应在应用系统中记录当前分支号，以便后续回滚使用。
- 在部署过程中出现问题，由对应负责人及时解决，如果问题不能在发布的计划时间内予以解决，则执行回滚方案。
- 运维及DBA在操作完成时，均需要回复邮件，并说明操作结果。
- 发布完成后，运维人员邮件通知测试人员，业务及需求相关人员进行线上测试。
- 测试结果及问题、提交开发， 如果出现问题不能在计划时间内解决， 执行回滚方案，并重新进行迭代。
2、金丝雀发布（灰度发布）
金丝雀发布的思想则是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的机器。验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本，期间可以根据设置的流量比例，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源得到最大化利用。
3、发布结果
通过金丝雀发布，需要比较长的时间才能将新的版本全部替换到服务器上，但是风险更小、底层资源消耗更少。
发布完成之后，需要将发布结果通知到相关责任人：
- PM： 周知PM关注业务指标、客诉等
- 上游：如果上游依赖此发布，周知上游开始发布
- 下游：周知下周注意流量增量及耗时等情况
五、 运维监控
运维人员持续对线上业务进行有计划的监控及日志采集, 及时发现问题处理及反馈问题。
常用的的监控报警包括：
- 新、旧版本的流量及百分比
- 对外提供的接口的性能指标、下游的性能指标（TP50、TP90、TP99、TP999）
- 异常指标及报警
- 业务指标
六、总结
在平时工作中，都是做好了万全的准备之后，才会执行上线的，但是整个过程也很难保证100%成功，因此做好完善、规范的防范措施很重要：
- 不在高峰期上线，如必须上线，要发邮件申请，同时降低并发度
- 上线前周知
- 保证能回滚
- 发布过程采用分组发布（强制）
- 上线过程中观察系统指标、业务指标、异常指标等；如有异常立即禁用已发布机器
- 上线后周知PM、上下游等
- 有异常第一时间回滚
ALLEN老师软件测试小课堂：
https://zhuanlan.zhihu.com/p/550021486
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。