配置管理：测试环境、验证环境、生产环境与CI/CD
推荐阅读
技术决策者 | 项目经理 | 高级技术人员 | 初级技术人员 | 测试人员 |
|---|---|---|---|---|
√ | √ | √ |
type=info
本文中的实践在管理上较为复杂，可控性高但投入大，更推荐用于中大型项目或高价值的核心应用场景。
一、为什么要搭建多套环境？
在实际项目中，为了确保开发工作的有序可控，强烈推荐您严格区分和管理包括测试环境、验证环境与生产环境。如果测试环境或验证环境与生产环境混杂在一起（如共用同一个数据库），很可能会因为误操作，破坏最终用户的数据；如果测试环境和验证环境混杂一起，在针对最终用户反馈的问题进行调查时，会发生与常规测试争抢和冲突的情况，影响总体效率。
在常规团队中，三套环境的主要差异如下：
生产环境 | 测试环境 | 验证环境 | |
|---|---|---|---|
软件环境 | 按实际应用场景规划 | 与生产环境保持一致 | 与生产环境保持一致 |
管理权限 | 运营团队 | 测试团队 * | 开发团队 |
硬件与架构 | 按实际应用场景规划 | 能满足测试工作即可 | 架构上与生产环境一致，计算资源可进行缩减 |
数据生命周期 | 原则上“不删档” | 定期重置 | 定期从生产环境中获取 |
数据敏感性 | 敏感数据 | 非敏感数据 | 非敏感数据（构建验证环境时，需进行脱敏处理） |
应用版本 | master分支，release版本 ** | develop分支，Daily Build *** 的版本 | 与生产环境版本一致 |
* 考虑到活字格的授权模式，强烈推荐在每个测试人员的工作电脑上安装活字格服务管理器，在自己的机器上进行测试，而不是集中使用同一台服务器
** 多分支管理方案，请参考：如何通过版本管理让开发更有序？
*** Daily build方案，请参考：如何使用命令行获取Git协同工程、打包和发布
二、一个中大项目的配置管理工作清单
2.1 CI/CD
项目从原型转向正式开发后，需要尽快完成持续集成的搭建，最迟也要在测试人员进场前完成。
CI/CD是配置管理的核心，也是非常有价值的实践。活字格的持续发布机制依托于活字格设计器，所以需要在安装有设计器的Windows机器上执行。如果采用TeamCity或Jekins的话，需要使用Windows版Agent执行，Agent的执行身份需要使用有桌面登录权限的用户，而不能使用System，否则发布环节会出现类似于URI解析等错误。
数据库层面的发布，请沿用编码开发时的持续发布方案。
详细了解：
2.2 日常开发流程
日常开发指按计划开展的开发项目，目标为交付某个特定的版本。开发阶段主要使用的是测试环境，开发人员和测试人员均在测试环境上开展工作。
【推荐】为测试环境启用持续集成
【建议】测试环境中，推荐开启全部日志
【建议】有条件的话，让测试环境和生产环境保持一致，详细了解：如何搭建生产环境
【建议】测试环境用到的活字格服务器、数据库服务器、操作系统等的版本要求与生产环境保持一致，硬件配置可酌情降低
【建议】搭建和更新测试环境时使用的工程和数据库脚本均来自develop分支
【参考】为了保证测试工作有序，除非必要，不推荐向开发人员提供测试环境和数据库的管理员密码，所有发布均需要采用持续集成工具完成，可控、留痕
【参考】每个版本发布后，建议使用当前最新的数据库结构和内置数据脚本重置测试环境的数据库，具体做法为依次执行初始化脚本和之前每一个版本的差分升级脚本
【参考】除非必要，不推荐直接修改测试环境数据库的结构和内置数据，如需变更，请确保先更新数据库结构和内置数据的初始化（初版上线前）或当前版本的差分升级（初版上线后）脚本
【参考】预算有限的情况下，可以在每个参与测试的人员电脑上安装和部署测试服务器和应用，确保数据库（业务数据库和用户数据库）相同即可
2.3 版本发布
发布工作由DevOps完成，如果团队规模较小，可由项目的技术负责人兼任。初版发布后，每一次发布之前，均需要先在验证环境下执行升级和验证，确认无误后方可操作生产环境。
【推荐】根据项目实际情况配置生产环境，详细了解：如何设计生产环境的部署方案？
【推荐】严格控制生产环境的访问权限，开发和测试人员均不能对应用和数据进行操作
【推荐】验证环境与生产环境的部署方式尽量与测试环境保持一致（只是分支不同），避免因打包方式差异带来的问题
【推荐】对生产环境进行任何会导致应用或数据变化的操作前，都强烈推荐在与生产环境的架构与数据一致的验证环境上测试，确认无误后方可在生产环境上执行
【建议】确保git仓库中master分支的内容与生产环境保持一致，开发团队可根据习惯，选择先将develop分支合并到master后再从master分支拉取工程发布，或先使用develop分支拉取工程发布后，再将develop分支合并到master
【建议】建立定时的数据备份机制，在建立验证环境时，数据库可使用经脱敏的生产环境备份构建
【建议】验证环境中，推荐开启全部日志
【建议】生产环境中，推荐开启“异常日志”、“HTTP响应”日志，视安全性要求开启“登录日志”、“登出日志”、“忘记密码日志”等三个安全类日志；在版本发布初期还可临时性开启“服务端命令”日志和“SQL日志”，能有效提升出现故障后进行调查的效率
2.4 故障调查
线上运行的环境出现故障时，需使用验证环境尽量还原生产环境中的配置和数据，稳定再现问题，可有效提升故障处理的效率。
【推荐】不要在生产环境上进行有可能影响到最终用户的调查和操作
【推荐】一旦系统上线，不要在正常运行的生产环境上做压力测试！
【建议】调查时，可使用git仓库中的master分支建立与验证环境，根据最终用户描述配合日志找到问题点后，再验证环境中进行复现
【建议】确定要通过发布hotfix的方式进行问题修复时，先基于master创建hotfix分支；开发者在这个分支中提交修复
【建议】Hotfix的发布流程与版本发布是一样的，依然需要谨慎对待
type=info
温馨提示
企业级低代码开发最佳实践是活字格官方面向进阶开发者推出的产品技术资源，旨在帮助对活字格基本功能有一定了解的开发者快速提升应用开发能力，保质保量做好企业级项目交付。如果您是初次接触活字格，这些内容可能会有些艰深难懂，这也是正常的。如果您有软件开发经验，推荐您学习《面向程序员的活字格入门课程》；否则，您也可以免费报名参加新手训练营直播课程或购买阅读《低代码开发实战：基于低代码平台构建企业级应用》（机械工业出版社），快速上手低代码开发。