5月软件版本稳定性提升：星月团队关键措施和改进总结

* Code never lies, comments sometimes do. *

    本文的思路如下：

    在4月份的事故后，做了一次复盘：一次软件产品的线上故障复盘。同时星月同学带领的团队，在5月份采取了一系列措施来确保本次上线服务的稳定性。以下是详细的落地措施和改进方案：

    1. 前端人员升级

    由于上次事故是由前端人员的代码覆盖导致的，这次替换为更有经验的前端人员。此外，原来的新手程序员也被调至其他项目，确保代码的质量和稳定性。

    2. 详细设计和代码评审

    本次版本除了前端代码的修改，还涉及后端代码的修改。具体措施包括：

• 详细设计：由后端人员进行详细设计，并组织PM（产品经理）、RD（研发人员）、QA（质量保证人员）进行评审。在评审过程中，记录并跟进所有提出的Todo项，确保每个问题都得到改进和解决。

• Code Review：代码提交后，由其他RD进行评审。如果有觉得不妥的地方可以 -1来阻止代码上到生产环境。

    3. 回归测试和增量测试

    上次由于缺乏充分的测试环节导致问题，这次加强了测试力度。

• 自测和QA测试：研发人员在公有云测试环境中进行自测，之后由QA人员进行公有云测试环境的测试，再由运维人员进行私有云测试环境的测试，最后由用户在私有云生产环境中进行验证。

• 分阶段测试：测试分为三个主要阶段：公有云测试环境、私有云测试环境和私有云生产环境。确保每个阶段的测试都覆盖全面。

图1. 测试流程

    4. 代码提交Review环节改进

    目前，由于历史原因，代码Review是在提交到远端代码库并合并到Master分支时进行的。为了改进这一环节，未来计划将代码Review前置到代码提交到远端代码库之前进行，确保问题在早期被发现和解决。

    5. 遇到的问题及解决方案

    在上线过程中遇到两个主要问题，并分别采取了相应的解决措施：

    1）不同环境的Python版本问题：

• 问题描述：由于历史原因，后端部分代码使用Python编写，不同环境下的Python版本不同导致import magic number error。

• 解决方案：在公有云开发环境中使用Python 3.11编译生成的pyc二进制代码，在私有云测试环境中遇到问题后，改为使用Python 3.6编译，问题解决。

    2）编译打包后的自动化部署问题：

• 问题描述：由于工程能力不足，部署无法完全自动化，Jenkins打包后不会触发自动部署。

• 解决方案：使用Python编写脚本，监听包文件的变化（通过MD5方式），检测到变化后自动部署，最终实现打包到部署的闭环。

图2. 打包流程

图3. 自动化部署流程

    6.资源有限情况下的努力

    尽人事，听天命。在公司资源有限的情况下，团队已经尽可能采取了所有可行的措施，以确保本次生产环境的稳定性。

    总结

    本次改进措施表明，所带领的团队在态度上非常重视，并且采取了实际的行动来改进工作流程和技术细节。当前已经完成了所有预上线的测试步骤，静待生产环境的验证。未来，团队将继续优化代码提交和Review流程，同步提升自动化部署的工程能力。