Skip to content

孙克 / smf-core

转到一个项目
切换导航栏
切换导航栏固定状态
切换分支/标签
ci-cd-pipeline.md 28.0 KB

SMF Core 项目 CI/CD 流水线文档

1 概述

本文档描述了 smf-core 项目的持续集成和持续部署（CI/CD）流水线。项目采用基于 Git 分支的双流水线策略，包含完整的代码合并、测试验证和售后交付流程。该流程通过钉钉 OPL 文件进行问题反馈和 Bug 追踪，实现了开发、测试、交付的全流程自动化管理2。

1.1 文档版本

版本号 修订日期 修订内容 修订人
1.0 2022-03-15 初始版本，建立基础 CI/CD 流程 技术架构组
1.1 2022-06-20 优化部署脚本，增加自动化测试 技术架构组
1.2 2022-09-10 完善部署流程，补充 Linux 版本脚本 技术架构组
2.0 2023-01-15 重构分支策略，引入 feature 分支管理 技术架构组
2.1 2023-05-08 增加安全扫描和代码质量门禁 技术架构组
2.2 2024-12-08 集成钉钉 OPL 反馈机制 技术架构组

1.2 术语说明

  • CI/CD: 持续集成/持续部署
  • OPL: 现场问题日志
  • SNAPSHOT: 开发快照版本
  • WAR: Web应用归档文件
  • GitLab: 代码仓库管理平台
  • Maven: Java项目构建工具

2 流水线架构

2.1 整体流程

流水线架构

flowchart TD

%% 代码提交与触发
A[开发人员提交代码] --> B[GitLab触发流水线]
B --> C{分支判断}

%% 开发构建流水线
C -->|develop| D
subgraph D[开发构建流水线]
    D1[代码编译] --> D2[运行单元测试]
    D2 --> D3[代码质量检查]
    D3 --> D4[生成SNAPSHOT包]
end

%% 发布构建流水线
C -->|master| E
subgraph E[发布构建流水线]
    E1[完整代码编译] --> E2[运行全量测试]
    E2 --> E3[代码安全扫描]
    E3 --> E4[生成WAR包]
    E4 --> E5[内部测试验证]
    E5 --> E6[交付售后团队]
    E6 --> E7[设备功能验证]
    E7 --> E8{验证结果}
end

%% 验证结果处理
E8 -->|通过| E9[标记为发布版本]
E8 -->|失败| E10[人工创建OPL文件]
E10 --> E11[钉钉群通知开发团队]
E11 --> E12[开发团队处理OPL]
E12 --> E13[问题修复验证]

%% 合并请求流程
D4 --> F[等待合并请求]
F --> G[创建Merge Request]
G --> H[代码审查]
H --> I[批准合并]
I --> J[合并到master]
J --> E1

3 环境配置

3.1 构建环境

  • 代码仓库: 自建 GitLab 服务器 (版本: 14.0+)
  • 构建工具: Maven 3.6+
  • JDK 版本: 1.8(建议: JDK 8u191+)
  • 操作系统: Linux/Windows
  • 开发环境: application-dev.yml
  • 测试环境: application-test.yml
  • 生产环境: application-prod.yml

3.2 目标环境

  • 应用服务器: Tomcat 8.5+ (建议: 8.5.57+)
  • 数据库: MongoDB 4.0+ (建议: 4.2.15+)
  • 部署位置: 客户本地内网设备

4 分支管理策略

4.1 分支类型

  • master: 生产就绪代码，仅接受合并请求
  • develop: 开发集成分支，持续集成测试
  • feature/功能名称-日期: 功能开发分支 (示例: feature/user-login-1208)
  • hotfix/问题描述-日期: 紧急修复分支 (示例: hotfix/login-error-1208)
  • release/版本号-日期: 发布分支 (示例: release/5.12.0-1208)

4.2 分支保护规则

  • master分支: 需要至少2人代码审查
  • release分支: 禁止直接推送，只能通过合并请求

5 流水线详细流程

5.1 代码提交阶段

提交信息规范:

  • 格式: 类型(模块): 描述
  • 示例: feat(user): 增加用户登录功能
  • fix(order): 修复订单创建异常

触发机制:

  • 开发人员推送代码到 GitLab 仓库
  • GitLab Webhook 自动触发相应流水线

分支策略:

  • develop分支 → 开发构建流水线（集成测试）
  • master分支 → 发布构建流水线（生产就绪）

5.2 开发构建流水线 (develop分支)

5.2.1 代码编译


mvn clean compile -Pdev -Dmaven.compiler.source=1.8 -Dmaven.compiler.target=1.8

5.2.2 运行单元测试


mvn test -Pdev -DskipTests=false -DfailIfNoTests=true

单元测试标准

  • 单元测试覆盖率: ≥80%
  • 代码行覆盖率: ≥70%
  • 分支覆盖率: ≥60%

5.2.3 代码质量检查


mvn checkstyle:check pmd:check cpd:check

代码质量检查标准

  • Checkstyle: 零错误
  • PMD: 最多5个警告
  • 重复代码: ≤3%

5.2.4 生成SNAPSHOT包

mvn deploy -Pdev -DskipTests=true

5.3 合并请求流程

5.3.1 创建合并请求

前提条件:

  • develop 分支构建成功
  • 所有测试用例通过
  • 代码质量检查达标

5.3.2 代码审查标准

  • 代码符合编码规范
  • 业务逻辑正确性
  • 安全风险检查
  • 测试覆盖充分性1

5.4 发布构建流水线 (master分支)

5.4.1 完整代码编译

mvn clean compile -Pprod

安全扫描失败标准

  • 致命漏洞: 0个
  • 严重漏洞: ≤2个
  • 中等漏洞: ≤5个

5.4.2 运行全量测试

mvn verify -Pprod -DskipTests=false

5.4.3 代码安全扫描

mvn org.owasp:dependency-check-maven:check

mvn org.sonarsource.scanner.maven:sonar-maven-plugin:sonar

安全扫描配置

<!-- 在pom.xml中添加 -->
<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>6.5.3</version>
    <configuration>
        <failBuildOnAnyVulnerability>true</failBuildOnAnyVulnerability>
    </configuration>
</plugin>

5.4.4 生成WAR包

mvn clean package -Pprod -DskipTests=true

5.4.5 内部测试验证

测试环境隔离要求:

  • 测试数据库与生产环境隔离
  • 测试数据使用模拟数据
  • 网络环境模拟客户内网

测试环境搭建:

#!/bin/bash
# setup-test-env.sh - 内部测试环境准备

# 1. 部署到测试服务器
scp target/smf-core-*.war test-server:/opt/tomcat/webapps/

# 2. 重启服务
ssh test-server "systemctl restart tomcat"

# 3. 等待服务启动
sleep 30

# 4. 执行自动化测试
mvn test -Ptest -Dtest.environment=internal

测试验证清单:

  • 基础功能测试通过
  • 接口兼容性验证
  • 性能基准测试达标
  • 安全功能验证
  • 文档完整性检查

5.4.6 交付售后团队

交付包生成（Maven标准化方式）:

通过Maven Assembly插件直接生成标准化交付包，在pom.xml中配置：

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>3.6.0</version>
            <configuration>
                <descriptors>
                    <descriptor>src/assembly/delivery.xml</descriptor>
                </descriptors>
                <finalName>smf-core-${project.version}-delivery</finalName>
                <appendAssemblyId>false</appendAssemblyId>
            </configuration>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

交付包内容描述: 交付包通过Maven自动生成，包含以下标准化内容：

  • smf-core-{version}.war- 应用程序WAR文件
  • deploy.sh- 标准化部署脚本
  • rollback.sh- 回滚脚本
  • release-notes.md- 版本说明文档
  • verification-checklist.md- 验证清单

交付验证清单:

  • WAR文件MD5校验通过
  • 部署脚本权限正确(chmod +x)
  • 版本号与交付包一致
  • 依赖文件完整无缺失

交付通知流程:

  1. Maven构建系统自动生成标准化交付包

  2. 在钉钉群中发布交付通知

  3. 售后团队下载交付包进行验证

  4. 如发现问题，按OPL流程反馈

5.4.7 现场部署与回滚流程

核心操作流程:

整个部署与回滚过程遵循以下标准化流程，确保操作的可追溯性与安全性

flowchart TD A[收到交付包] --> B[环境预检] B --> C{服务运行?} C -- 是 --> D[停止Tomcat服务] C -- 否 --> E[备份当前版本] D --> E E --> F[部署新WAR包] F --> G[启动Tomcat服务] G --> H[验证部署结果] H --> I{验证成功?} I -- 是 --> J[部署成功] I -- 否 --> K[触发回滚流程] K --> L[执行回滚操作] L --> M[回滚成功]

标准部署流程: 此脚本用于将新版本应用安全地部署到生产环境。

  1. 环境预检与服务停止
@echo off
echo [SMF Core] 开始执行标准部署流程...
echo 当前时间: %date% %time%

echo.
echo [1/5] 检查Tomcat服务状态...
sc query TomcatSMF | find "RUNNING" >nul
if %errorlevel% equ 0 (
    echo 检测到Tomcat服务正在运行，准备停止...
    net stop TomcatSMF
    timeout /t 10 /nobreak >nul
    echo Tomcat服务已停止。
) else (
    echo Tomcat服务未运行，继续执行部署。
)
  1. 备份当前版本（关键步骤）

echo.
echo [2/5] 备份当前应用版本...
set "backup_dir=D:\smf-backups\backup_%date:~0,4%%date:~5,2%%date:~8,2%_%time:~0,2%%time:~3,2%"
mkdir "%backup_dir%" 2>nul

xcopy "D:\tomcat\webapps\smf-core.war" "%backup_dir%\" /Y >nul
xcopy "D:\tomcat\webapps\smf-core" "%backup_dir%\smf-core\" /E /I /Y >nul 2>nul

if exist "D:\tomcat\webapps\smf-core.war" (
    echo 应用备份已完成: %backup_dir%
) else (
    echo 注意: 未发现旧版WAR文件，此为首次部署。
)
  1. 清理旧文件与部署新版本
echo.
echo [3/5] 清理旧文件并部署新版本...
cd /d "D:\tomcat\webapps"

del smf-core.war 2>nul
rmdir smf-core /S /Q 2>nul

copy "%~dp0smf-core-*.war" "smf-core.war" >nul
echo 新版本WAR包已复制到位。
  1. 启动服务并验证
echo.
echo [4/5] 启动Tomcat服务...
net start TomcatSMF
timeout /t 15 /nobreak >nul
echo Tomcat服务启动命令已执行。

echo.
echo [5/5] 验证部署结果...
timeout /t 5 /nobreak >nul
curl -s -f http://localhost:8080/smf-core/health >nul
if %errorlevel% equ 0 (
    echo ✅ 部署成功！健康检查接口正常。
    echo 请进行后续业务功能验证。
) else (
    echo ❌ 健康检查失败！将自动触发回滚流程...
    call "%~dp0rollback.bat"
    exit /b 1
)

紧急回滚流程 (rollback.bat):

当新版本出现问题时，使用此脚本快速恢复到上一个稳定版本。

@echo off
echo [SMF Core] 启动紧急回滚流程...
echo 当前时间: %date% %time%

echo.
echo [1/4] 停止Tomcat服务...
net stop TomcatSMF
timeout /t 10 /nobreak >nul

echo.
echo [2/4] 查找最新的备份文件...
for /f "delims=" %%i in ('dir D:\smf-backups /ad /b /od 2^>nul') do set "latest_backup=%%i"
if "%latest_backup%"=="" (
    echo ❌ 未找到任何备份目录，无法回滚。请手动处理。
    exit /b 1
)
set "backup_path=D:\smf-backups\%latest_backup%"

echo.
echo [3/4] 恢复备份版本...
cd /d "D:\tomcat\webapps"
del smf-core.war 2>nul
rmdir smf-core /S /Q 2>nul

copy "%backup_path%\smf-core.war" "." >nul
if exist "%backup_path%\smf-core" (
    xcopy "%backup_path%\smf-core" "smf-core\" /E /I /Y >nul
)
echo 已回滚至备份: %latest_backup%

echo.
echo [4/4] 启动Tomcat服务...
net start TomcatSMF
echo ✅ 回滚完成。请验证业务功能是否恢复正常。
echo *** 重要: 务必在钉钉创建OPL，记录此次回滚事件！***

现场操作清单

阶段 操作项 负责人 完成确认 (✓)
部署前 1. 确认已收到完整的交付包（含WAR包和本脚本） 售后人员
部署前 2. 通知客户相关人员即将开始系统维护 售后人员
部署中 3. 双击运行 deploy.bat，观察命令行输出 售后人员
部署中 4. 脚本自动完成：停服务、备份、部署、启动、健康检查 自动化脚本
部署后 5. 与客户共同验证核心业务功能 售后人员/客户
部署后 6. 确认一切正常，在部署记录单上签字确认 售后人员/客户
回滚 7. （若异常）运行 rollback.bat或根据脚本提示自动回滚 售后人员
回滚 8. 验证回滚结果，并创建OPL文件记录回滚原因 售后人员

常见问题与故障排除

现象 可能原因 解决步骤
部署脚本执行失败 1. 命令行窗口权限不足
2. 防病毒软件拦截
3. 文件路径不正确		 1. 以管理员身份运行CMD，然后执行脚本
2. 暂时禁用防病毒软件或添加信任
3. 检查 deploy.bat 和 rollback.bat 是否与WAR包在同一目录
Tomcat服务无法启动 1. 新WAR包损坏或版本不兼容
2. 端口被占用
3. 内存不足		 1. 执行回滚，确认是否为版本问题。检查WAR包MD5码
2. 运行 `netstat -ano \
健康检查通过但业务功能异常 1. 数据库连接问题
2. 缓存数据未更新
3. 特定功能逻辑错误		 1. 检查数据库服务是否正常，连接字符串是否正确
2. 尝试清空应用缓存或重启服务
3. 立即创建OPL文件，详细描述问题现象和复现步骤

6. OPL（现场问题日志）创建指引

6.1 必须创建OPL的情况

  • 部署或回滚后，任何业务功能无法正常使用。
  • 系统性能显著下降，如页面加载超时、事务处理缓慢。
  • 出现任何错误提示或异常日志。
  • 执行了回滚操作。

6.2 OPL响应时间标准

  • 紧急: 2小时内响应
  • 高: 4小时内响应
  • 中: 8小时内响应
  • 低: 24小时内响应

6.3 OPL信息填写要点

  • 编号: OPL-YYYYMMDD-序号, 示例: OPL-20241208-001
  • 标题：清晰概括问题，例如：“V5.12版本部署后用户登录失败”。
  • 项目编号: 设备所属的项目编号
  • 发现版本：准确填写部署的版本号。
  • 发现人员: [姓名]
  • 发现时间: YYYY-MM-DD HH:MM
  • 复现步骤：详细描述操作步骤，便于开发人员重现问题。
  • 日志与截图：务必附上Tomcat日志文件 (catalina.out) 和相关界面的截图。
  • 状态: 新建 → 分配中 → 处理中 → 待验证 → 已解决 → 已关闭
  • 优先级:
    • 紧急: 系统完全不可用，影响核心业务
    • 高: 主要功能异常，但有变通方案
    • 中: 次要功能问题，不影响主要业务
    • 低: 优化建议或界面显示问题

6.4 OPL状态流转规则

stateDiagram-v2
    [*] --> 新建
    新建 --> 分配中 : 售后提交
    分配中 --> 处理中 : 开发负责人分配
    处理中 --> 待验证 : 开发完成修复
    待验证 --> 已解决 : 售后验证通过
    待验证 --> 处理中 : 售后验证失败
    已解决 --> 已关闭 : 问题确认解决
    已关闭 --> [*]

6.5 OPL文件跟踪要求

  • 每天查看分配的OPL处理进展
  • 及时回复开发人员的询问
  • 验证修复后确认问题解决
  • 更新OPL状态为"已关闭"

6.6 紧急问题处理流程

对于严重影响设备运行的紧急问题：

  1. 立即电话通知开发负责人

2.创建OPL文件并标记为"紧急"

3.持续跟踪直至问题解决

  1. 记录处理过程供后续参考

7. 监控和反馈机制

7.1 项目追踪看板

  • 版本号: x.xx.xxxx
  • 状态: 设备验证中
  • OPL数量: x个（x个处理中，x个待验证）
  • 预计完成: yyyy-mm-dd
  • 构建成功率: 95%
  • 平均构建时间: ≤15分钟
  • 部署成功率: 98%
  • 问题平均解决时间: ≤8小时

7.2 OPL处理流程

graph TD A[售后发现问题] --> B[创建OPL文件] B --> C[钉钉群通知开发团队] C --> D[开发负责人分配任务] D --> E[开发人员分析问题] E --> F{问题类型} F -->|紧急| G[创建hotfix分支] F -->|普通| H[安排下版本修复] G --> I[快速修复验证] I --> J[紧急发布] H --> K[常规开发流程] J --> L[售后验证修复] K --> L L --> M[关闭OPL文件]

7.3 沟通协调机制

钉钉群组分工:

  • 开发群: 技术讨论、代码审查、问题分析
  • 发布群: 版本发布通知、部署协调
  • 项目群: 项目相关问题沟通
  • 售后群: 现场问题反馈、客户沟通
  • 紧急事务: 电话直接联系相关负责人

会议机制:

  • 每日例会: 同步开发进度和问题
    1. 昨日完成工作
    2. 今日计划工作
    3. 遇到的阻塞问题
    4. OPL处理进展
  • 周评审会: 版本计划和OPL处理情况
  • 月度总结: 流程优化和改进措施

8. 应急预案

8.1 生产环境故障处理流程

  1. 立即响应

    • 确认问题影响范围
    • 通知相关责任人
    • 启动紧急回滚流程

  2. 问题定位

    • 收集错误日志和监控数据
    • 分析问题根本原因
    • 评估修复方案

  3. 修复验证

    • 开发修复补丁
    • 测试环境验证
    • 生产环境部署

  4. 事后复盘

    • 问题根本原因分析
    • 流程改进措施
    • 文档更新

9. 性能优化指南

9.1 构建性能优化

  • 使用Maven镜像仓库加速依赖下载
  • 配置依赖缓存减少网络请求
  • 并行执行测试用例缩短构建时间

9.2 部署优化

  • 增量部署减少停机时间
  • 蓝绿部署实现零停机发布
  • 健康检查确保服务可用性
核心目标 推荐插件 主要功能简介
:hammer: 运行单元测试 maven-surefire-plugin Maven 默认内置，用于在 test 阶段运行你的单元测试（类名需符合 *Test.java 等模式）。
🧪 运行集成测试 maven-failsafe-plugin 专为集成测试设计，在 integration-test 和 verify 阶段运行（类名需符合 *IT.java 等模式）。其特点是即使测试失败，也会继续完成构建过程，确保清理资源，故名为 "failsafe"（安全失败）。
:bar_chart: 生成测试覆盖率报告 jacoco-maven-plugin 在测试运行时收集覆盖率数据，并可在 verify 阶段生成详细的 HTML 或 XML 格式的报告，直观展示代码行、分支等的覆盖率。
:straight_ruler: 检查代码风格规范 maven-checkstyle-plugin 根据预定义或自定义的编码规范（如 Google Java Style）检查代码风格，确保团队代码一致性。
:bug: 检测代码潜在缺陷 spotbugs-maven-plugin 分析字节码，找出潜在的 Bug（如空指针、资源未关闭、逻辑错误等），是 FindBugs 的现代版。
🧹 分析代码设计与复杂度 maven-pmd-plugin 提供更深入的代码质量分析，能检测未使用的变量、重复代码、复杂的代码块等问题，帮助优化代码结构。

测试报告, 及质量分析

flowchart TD A[开发者提交代码至Git仓库] --> B[CI服务器触发自动化构建]

subgraph Java项目流水线 direction TB C1[清理
maven-clean-plugin] --> C2[编译
maven-compiler-plugin] C2 --> C3[运行单元测试
maven-surefire-plugin] C3 --> C4[打包
maven-jar-plugin/war-plugin] C4 --> C5[运行集成测试
maven-failsafe-plugin] C5 --> C6[执行代码质量分析
质量工具集] end

subgraph C6_Details [代码质量分析详情]
    direction LR
    D1[静态缺陷检查<br>spotbugs-maven-plugin] --> D2[代码规范检查<br>maven-checkstyle-plugin]
    D2 --> D3[设计与复杂度分析<br>maven-pmd-plugin]
    D3 --> D4[测试覆盖率分析<br>jacoco-maven-plugin]
end

subgraph CSharp项目流水线
    direction TB
    E1[编译<br>dotnet build / MSBuild] --> E2[运行测试<br>dotnet test]
    E2 --> E3[代码质量分析<br>.NET 质量工具集]
end

subgraph E3_Details [代码质量分析详情]
    direction LR
    F1[静态分析<br>Roslyn 分析器] --> F2[测试覆盖率分析<br>Coverlet]
end

B --> Java项目流水线
B --> CSharp项目流水线

Java项目流水线 --> G[生成多维度分析报告<br>HTML/XML/控制台]
CSharp项目流水线 --> G

G --> H{是否已集成SonarQube？}
H -->|是， 未来统一平台| I[上传分析结果<br>sonar-maven-plugin / SonarScanner for .NET]
H -->|否， 当前分散模式| J[报告保存于本地<br>或CI服务器目录]

I --> K[SonarQube 平台<br>集中可视化、管理与质量门禁]
J --> L[报告独立分散]

K --> M[生成统一的<br>质量仪表盘与报告]
L --> M

1. 版本历史（回顾）

版本号 发布日期 核心功能/主题 技术栈/备注
SMD Box v1.0 2020年底 核心架构确立：实现锡膏料仓管理、扫码料架操作、工单出库等基础业务流程 技术栈：传统单体架构。标志着产品原型诞生
SMD Box v1.5 2021年下半年 功能深化与定制化：为客户开发看板、呆滞物料提醒等定制功能 体现了从通用产品向满足特定客户需求的转变
SMD Box v2.0 2023年上半年 架构拓展与新硬件支持：支持SMD Box方舱等复杂硬件，完成与PanaCIM系统对接 为后续升级为SMF平台奠定硬件集成基础
SMF v1.0 2022年底 平台重构与现代化：全面升级至Spring Boot + Vue.js + MongoDB技术栈 里程碑：从"工具软件"向"平台化产品"战略转型
SMF v2.0 2023年中 锡膏料仓核心功能成熟：完整实现锡膏料仓的专业化功能 在新技栈上实现关键业务模块的深度覆盖
SMF v3.0 2024年初 体验与架构优化：实现单点登录，增强安全配置，包含虚拟回仓等重大更新 重点关注企业级部署的安全性和用户体验
SMF v4.0 2024年4月 模块化与可扩展性提升：重构核心设备控制逻辑，增强系统可配置性 为支持更多设备类型和客户定制打下基础
SMF v5.0 2024年10月 核心逻辑重大升级：重构入库验证、库位查找等底层逻辑，引入Fuji对接 深刻的底层架构优化，提升系统性能和稳定性
SMF v5.9 2025年7月 虚拟仓功能上线：重新引入成熟的"虚拟仓"功能，支持Nexim设备在线操作 标志着高级功能在SMF平台上的成功落地
SMF v5.12 2025年10月 MES集成深化：优化尾料仓功能，实现工单状态改变实时通知MES 展现与上层系统的深度集成能力
SMF v5.14 2025年11月 流程精细化与稳定性提升：尾料管理增强、双库位操作、设备集成优化 提升仓库操作体验和系统稳定性

2. 发布日历（展望）

版本号 预计发布日期 核心功能/主题 当前状态 价值主张
SMF v5.13 2025年12月 客户定制功能增强（Nexim, 中车）与系统优化 开发中 深化行业大客户合作，提升系统稳健性
SMF v5.15 2026年1月 年终稳定版：集中进行Bug修复、性能优化与文档完善 规划中 确保年度发布版本的极高可靠性
SMF v6.0 2026年第一季度 AI与智能运维探索：引入数据智能分析模块，支持预测性维护 规划中 将平台从"自动化"向"智能化"演进
SMF v6.1 2026年第二季度 多云/混合云部署支持与开放性API增强 规划中 满足大型客户对部署灵活性的高阶要求

1. Version History (Retrospective)

Version Release Date Core Features / Themes Technical Stack / Notes
SMD Box v1.0 End of 2020 Core Architecture Establishment: Implemented basic business processes for solder paste storage, barcode rack operations, and work order dispensing Tech Stack: Traditional monolithic architecture. Marked the birth of the product prototype
SMD Box v1.5 Second Half of 2021 Feature Deepening and Customization: Developed customized functions like dashboards and stagnant material alerts for clients Reflected the shift to meet specific customer needs
SMD Box v2.0 First Half of 2023 Architecture Expansion & New Hardware Support: Added support for complex hardware like SMD Box shelters, integrated with PanaCIM system Laid the hardware foundation for the SMF platform upgrade
SMF v1.0 End of 2022 Platform Refactoring & Modernization: Upgraded to Spring Boot + Vue.js + MongoDB tech stack Milestone: Strategic transition from "tool" to "platform"
SMF v2.0 Mid-2023 Solder Paste Storage Core Features: Fully implemented professional features including temperature control and reporting Achieved deep coverage of key business modules
SMF v3.0 Early 2024 Experience & Architecture Optimization: Implemented SSO, enhanced security, virtual return-to-warehouse features Focused on enterprise-level security and user experience
SMF v4.0 April 2024 Modularization & Scalability: Refactored core device control logic, improved configurability Foundation for supporting more device types and customization
SMF v5.0 October 2024 Major Core Logic Upgrade: Refactored inbound verification, location finding, added Fuji integration Significant architecture optimization for performance and stability
SMF v5.9 July 2025 Virtual Warehouse Launch: Re-introduced mature "Virtual Warehouse" with Nexim device support Successful implementation of advanced platform features
SMF v5.12 October 2025 MES Integration Deep Dive: Optimized tailings management, real-time work order status to MES Demonstrated deep integration with upper-level systems
SMF v5.14 November 2025 Process Refinement & Stability: Enhanced tailings management, dual-location operations, device integration Improved operational efficiency and system stability

2. Release Calendar (Forward-Looking)

Version Planned Release Date Core Features/Theme Current Status Value Proposition
SMF v5.13 December 2025 Customer-specific enhancements (Nexim, CRRC) and system optimization In Development Deepens collaboration with key customers, improves robustness
SMF v5.15 January 2026 Year-end stable release: Bug fixes, performance tuning, documentation Planned Ensures high reliability of annual release version
SMF v6.0 Q1 2026 AI and Predictive Maintenance: Data intelligence analysis for predictive maintenance Planned Evolves platform from "automation" to "intelligence"
SMF v6.1 Q2 2026 Multi-cloud/Hybrid deployment & Open API enhancement Planned Meets enterprise requirements for deployment flexibility

Summary

This document tracks the evolution from SMD Box (a single-function tool) to SMF (an enterprise platform), demonstrating continuous innovation and strategic growth in industrial material management solutions.

Document Version: 1.1 | Last Updated: 2025-12-11 | Contact: Technical Documentation Team

Code Quality Inspection Standards

Inspection Category Tools Maximum Tolerance Target Value Key Rules
Code Style Inspection Checkstyle (Java)
StyleCop (C#)		 0 Errors 0 Errors Naming conventions, indentation, comment standards
Code Defect Detection PMD (Java)
Roslyn Analyzers (C#)		 ≤5 Warnings 0 Warnings Null pointer exceptions, resource leaks
Duplicate Code Detection CPD (PMD)
SonarQube		 ≤3% ≤1% Duplicate code block identification
Code Complexity SonarQube
PMD		 Cyclomatic Complexity ≤15 Cyclomatic Complexity ≤10 Overly long methods, excessive nesting

Execution Requirements: Code style inspections should be configured with team-unified coding standard files and included in version control. For PMD warnings, categories must be distinguished—security-related warnings must be cleared, while code style warnings can be appropriately relaxed but require regular review.