唛盟xm：涵盖项目规划、需求管理、开发迭代、版本控制、缺陷跟踪、测试管理、工时管理、效能分析等环 节，实现项目全过程、全方位管理的一站式企业研发项目管理解决方案

👉 https://maimengcloud.com 👈

快速导航

• 前端组件
• 后端服务
• 体验环境 登陆界面上选择演示账号登陆(账号密码：demo-branch-01 888888)或者直接扫码登陆，无须注册
• 相关教程b站上搜素唛盟9哥教你撸前后端代码

📢 简介唛盟xm

唛盟企业级研发管理系统简称唛盟xm,属于唛盟生态的专业子系统之一，以研发管理为核心，涵盖项目规划、需求管理、开发迭代、版本控制、缺陷跟踪、测试管理、工时管理、效能分析等环节，实现全过程、全方位的研发管理。通过该系统，企业能够优化研发流程，提高研发效率，降低研发成本，提高市场竞争力。
💪给你一个使用唛盟的理由：代码大量减少、开发so easy、前后端MIT协议、全部开源、永久免费

📢 唛盟生态

💪唛盟生态遵循 “一个底座+N个专业子系统” 的架构，基于同一个底座的各个专业子系统可以任意组合形成一个大的业务系统。👉聊聊唛盟生态1+n架构

底座 mdp-core

mdp-core

N个专业子系统

⚙ 技术栈

1. 前端

2. 后端

⚙ 开发工具

前端
推荐 VS Code 开发，配合插件如下：

后端

😭 日常项目管理中，您是否有以下痛点？

需求管控困难

• 需求不明确：客户提出一些模糊的需求,这可能导致开发团队对需求的理解存在偏差。
• 信息分散、杂乱：需求可能散落在多个地方，如邮件、Excel表格、即时通讯工具、不同的项目组等无法进行统一管理。
• 需求追溯困难：提出者、评审者、实施人等不明确，导致责任不清、分工不明等问题产生。
• 需求与开发脱节：无法实时跟踪需求完成情况。无法实时定位需求进度落后原因，进而无法做出补救措施。
• 需求与测试不匹配：需求文档与测试用例不匹配导致测试工作无法顺利进行
• 需求变更频发：频繁变更需求，给开发团队带来很大的困扰。

任务管理困难

• 任务分配不明确：任务通过口头或邮件形式进行分配，这可能导致任务责任不明确和任务重叠。
• 任务发布、沟通困难：由于涉及的成员和部门众多，信息同步不及时，很容易导致项目协作混乱。
• 任务进度把控难：缺乏有效的工具来跟踪任务进度，团队成员很难准确把握项目的整体完成情况，也无法针对性地进行调整。
• 任务风险管理不充分：常常忽视任务风险管理，导致项目面临较大的风险。
• 工时统计困难：手动记录工时不仅容易出错，而且难以统计和分析，这不仅影响团队成员的个人成果统计，也影响团队之间的凝聚力和协作效果。

质量管理困难

• 质量标准不明确：缺乏明确的质量标准和规范，导致团队成员对质量要求的理解存在差异，从而影响软件质量。
• 质量保证不到位：导致软件存在缺陷和漏洞，影响用户体验和产品可靠性。
• 测试不全面：缺乏缺陷登记跟踪工具、缺乏测试用例管理工具，导致一些潜在问题未被发现和解决，从而影响软件质量。
• 质量管理与开发流程不融合：质量管理与开发流程相互分离，导致质量管理与开发效率相互影响，难以实现高效的软件开发。

缺乏协作&沟通

• 沟通渠道不统一：在开发团队中，不同的成员可能有不同的沟通渠道，导致信息分散，难以统一管理。
• 沟通不够及时：在开发过程中，有时沟通不够及时，导致一些重要信息滞后的处理，影响了项目进度。
• 沟通不够清晰：由于技术术语或背景知识的不同，团队成员之间的沟通有时不够清晰，导致理解上的偏差。
• 沟通缺乏反馈机制：在沟通中，有时缺乏反馈机制，导致对问题的处理不够及时和有效。

缺乏效能分析

• 缺乏组织级、项目级、产品级、团队级、个人级、迭代级等不同组织级别的效能分析：企业在长期项目实施过程中，未构建起从组织级到个人级的效能分析体系，无法全面掌握企业的项目运作全貌，进而无法有效进行资源调配，利益最大化。
• 缺乏对不同职能部门的多维度的效能分析
• 缺乏风险预警、风险分析
• 项目报告不全面、不准确
• 质量报告不全面、不准确
• 进度计划汇总、分解困难

解决之道

系统概况

系统特点

系统功能

技术架构

应用架构

项目总体管理

需求管理

项目计划

质量管理

迭代管理

效能分析

💪 功能展示

项目立项

项目总体

组织架构

项目报告

需求管理

用户故事

项目计划

项目计划-任务

迭代概览

迭代维护

测试管理

测试报告

缺陷管理

财务费用

驾驶舱

效能分析

燃尽图

每日工作项分布

任务年龄分布

任务排行棒

测试用例规划分析

客户端展示

小程序

审批管理

测试管理

💻 样例项目

• [低代码平台] (https://maimengcloud.com/lcode/)
• [协同办公] (https://maimengcloud.com/oa)
• [项目管理] (https://maimengcloud.com/xm)

⚙ 快速开始

⚠️注意：该项目使用 element plus 版本，所以最低兼容 vue@3.0+ nodejs版本v21.1.0

⚠️注意：强烈建议一定要用pnpm

// 全局安装
npm install pnpm -g
 
//查看源
pnpm config get registry 
//切换淘宝源
pnpm config set registry https://registry.npmmirror.com/
 
// 使用
pnpm install 包 // 安装依赖

前序准备

• 当前项目属于网页版前端ui项目，后端代码请移步到 xm-backend

开发

# 克隆项目
git clone https://gitee.com/maimengcloud/xm-ui-web.git

# 安装依赖
pnpm install 

# 启动服务
pnpm run dev

浏览器访问 http://localhost:8067

登录相关

登录api，对接后台接口有两种方式:

1. 对接统一认证中心

 VITE_CTX_LOGIN=oauth2client

2. 对接mdp-lcode-backend进行登录

 VITE_CTX_LOGIN=lcode

图片库、素材库、标签库

内容相关接口默认打包进mdp-lcode，所以内容相关接口可以直接对接lcode即可，如果内容相关的服务使用独立的第三方开源工程，独立部署，比如直接使用 mdp-arc-backend

1. 对接mdp-arc-backend

   VITE_CTX_ARC=arc

   # 配置附件上传的接口，如果不配使用arc内置的地址
   VITE_UPLOAD_ATT_URL=

   # 配置图片上传的接口，如果不配使用arc内置的地址
   VITE_UPLOAD_IMAGE_URL=
   

2. 对接mdp-lcode-backend

  VITE_CTX_ARC=lcode

  # 配置附件上传的接口，如果不配使用arc内置的地址
  VITE_UPLOAD_ATT_URL=

  # 配置图片上传的接口，如果不配使用arc内置的地址
  VITE_UPLOAD_IMAGE_URL=

前后端对接

开发的时候前后端对接有两种情况：

1. 本地运行前端工程、后端工程
   此种情况下前端如何把请求转发到本地起的后端工程？主要修改vite.config.js中的代理实现
   假设后端mdp-lcode启动，并监听7014端口

    ['/api/lcode']: {
      target: 'http://localhost:7014',
      ws: false,
      changeOrigin: true,
      rewrite: (path) => path.replace(new RegExp(`^/api/lcode`), '/'),
    },

    ['/api/xm']: {
      target: 'http://localhost:7067',
      ws: false,
      changeOrigin: true,
      rewrite: (path) => path.replace(new RegExp(`^/api/xm`), '/'),
    },

上述代理实现把以/api/lcode 开头的请求地址(举例/api/lcode/user/list)替换为/user/list,并转发到http://localhost:7014地址
上述代理实现把以/api/xm 开头的请求地址(举例/api/xm/user/list)替换为/user/list,并转发到http://localhost:7067地址

2. 只启动前端页面工程，后端工程不启动，后端工程使用服务器上的已启动的服务 此种情况下前端如何把请求转发到服务上起的后端服务？主要修改vite.config.js中的代理实现

    ['/api/lcode']: {
      target: '服务器上的ip:7014',
      ws: false,
      changeOrigin: true,
      rewrite: (path) => path.replace(new RegExp(`^/api/lcode`), '/'),
    },

    ['/api/xm']: {
      target: '服务器上的ip:7067',
      ws: false,
      changeOrigin: true,
      rewrite: (path) => path.replace(new RegExp(`^/api/xm`), '/'),
    },

构建

# 构建测试环境
pnpm run build:test

# 构建生产环境
pnpm run build:prod

发布

假设：

1. 应用服务器(sit1-backend),ip为192.168.0.222,端口7067
2. 静态资源服务器(sit1-static),ip为192.168.0.111
3. 反向代理使用nginx
4. 静态资源部署到服务器sit1-static的/data/nginx/html/xm/下
5. 本地*ui-web目录在C:/Users/xxx/IdeaProjects/xm-ui-web/

发布静态资源到测试\生产环境

# 1.首先登录sit1-static并进入/data/nginx/html/xm/下

cd /data/nginx/html/xm/
# 如果有dist.rar需要先删除
rm -rf dist.rar


# 2.执行rz命令，弹框选择本地dist文件上传到sit1-static服务器
rz 

# 3.在弹出的目录选择器中进入C:\Users\xxx\IdeaProjects\xm-ui-web\dist\目录下
全选所有文件->右键->添加到dist.rar->选中dist.rar->上传到服务器商/data/nginx/html/xm/目录下

# 4.执行解压缩命令，至此静态资源发布完成
unrar x dist.rar
解压后m1目录下一般有css、fonts、images、img、js、tinymce、favicon.icon、index.html等文件或者文件夹

nginx的配置

静态资源的访问映射

   location ~*/(mk|mallm|arc|im|sms|workflow|oa|ac|audit|xm|tpa|crowd|lcode) {
    root /usr/share/nginx/html;
    index index.html;
    expires 30d;
  }

xm相关api的映射配置(单体应用方式部署的后端)

    upstream api-gate-xm {
        server 192.168.0.222:7067;
    }

  location /api/xm/ {
    #proxy_redirect off;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://api-gate-xm/;
    proxy_connect_timeout 65s;
    proxy_send_timeout 65s;
    proxy_read_timeout 65s;
    proxy_next_upstream_tries 1;
  }

lcode相关api的映射配置(单体应用方式部署的后端)

    upstream api-gate-lcode {
        server 192.168.0.222:7014;
    }

  location /api/lcode/ {
    #proxy_redirect off;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://api-gate-lcode/;
    proxy_connect_timeout 65s;
    proxy_send_timeout 65s;
    proxy_read_timeout 65s;
    proxy_next_upstream_tries 1;
  }

需要特别注意的是 http://api-gate-lcode/后面的这个/不能省略，带/代表将“/api/lcode/”替换成“/”,再转发上送到目标服务器

同理，其它子系统的api也类似lcode一样配置，比如工作流相关的api可以按如下方式配置

    upstream api-gate-workflow {
        server 192.168.0.222:7080;
    }

  location /api/workflow/ {
    #proxy_redirect off;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://api-gate-workflow/;
    proxy_connect_timeout 65s;
    proxy_send_timeout 65s;
    proxy_read_timeout 65s;
    proxy_next_upstream_tries 1;
  }

api的映射配置(cloud方式部署的后端)

假设 spring cloud gate部署在192.168.0.222，监听6101端口 下面的目标服务器改为cloud gate的地址端口. 注意cloud环境下不需要像单体般每个子系统api单独配置映射关系。因为所有的api都是经过gate再转发的

    upstream api-gate {
        server 192.168.0.222:6101;
    } 
    location /api/ {
      #proxy_redirect off;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass http://api-gate/;
      proxy_connect_timeout 65s;
      proxy_send_timeout 65s;
      proxy_read_timeout 65s;
      proxy_next_upstream_tries 1;
  }

发布后端服务

具体以xm-backend中发布描述为准

运维

日志查询

日常查询问题，主要通过查询前后端日志，分析出具体原因，再进行针对性解决。 唛盟平台具有多个子业务系统，每个子业务系统都有独立日志，一个前端请求，可能日志散落在多个日志文件，如何才能凑齐这些日志，进行统一分析交易执行情况，进而定位问题？
答复：唛盟平台在每个请求到达服务端的时候，会检测gloNo是否存在，如果不存在，则会自动创建一个gloNo,并注入到日志上下文中，并打印到每一行代码中，另外请求结束，还会把gloNo返回到前端，如果交易中间涉及调用其他子系统，同样会自动上送gloNo，对方交易子系统同样执行上诉逻辑。因此，可以看见，gloNo是能够把所有日志串联起来的。我们只需要在日志文件目录下执行grep命令即可找出对应日志
操作步骤：
1.下面是典型的唛盟接口返回的数据结果集 gloNo就存放在res.data.tips.gloNo中。

{
  "total" : 1,
  "data" : [ {
    "bizFlowState" : null,
    "deptName" : null,
    "projectCnt" : 1,
    "admUserid" : "4hinb8m16",
    "del" : "0",
    "budgetNouserAt" : null,
    "productName" : "唛盟云-财务系统",
    "baselineId" : "2022-01-01-base-01", 
  }],
  "tips" : {
    "msg" : "成功",
    "gloNo" : "20240312200013556UWJZKV",
    "isOk" : true,
    "reqNo" : "20240312200013556JM3WKN",
    "tipscode" : "ok"
  }
}

2. 通过gloNo到logs目录下执行

grep "20240312200013556UWJZKV" *.log

服务状态监控

consule 的默认控制台 http://ip:8500/

有时候微服务需要人为干预进行下架

可以调用/bin/service-deregister.sh进行

日志定时备份清理

可以在crontab中配置定时任务，定时调用bin/clear-log.sh即可完成7天循环自动清理及备份日志

使用举例：

# 打开定时任务编辑器
crontab -e  
# 查看定时任务
crontab -l 
# 增加定时清理备份日志任务
0 1 * * * /bin/bash /home/mall/bin/clear-log.sh

🔔️ 开发计划与进度情况

3.x.x (当前版本，已完成大部分内容)

1. 所有的树状结构支持自由拖动，达到快速调整上下级关系目的
2. 任务、故事、计划、里程碑、缺陷、测试计划等分别支持动态看板、支持甘特图浏览编辑等
3. 增加预算管理、成本管理、预算与成本支出比对，任务结算管理等
4. 立项、预算变更、成本变更等重大节点提供流程审批功能
5. 进一步整合协同办公系统

4.x.x (下一版本，让我们一起拥抱ai起飞吧)

1. 提供接入大模型能力
2. 提供前端任意字段起调ai能力
3. 提供ai编程、ai测试、ai编排任务、ai需求整理能力
4. 提供ai出报告能力
5. 提供ai基于企业私有数字资产自训练能力

🗒️ 版本更新日志

2.0.0-RELEASE

已发布，停更

3.0.0-RELEASE

已发布，持续改进

4.0.0-BETA

预研中

📝 常见问题

唛盟xm基于唛盟低代码平台开发，问题都是共性的，请到唛盟低代码查看相关内容

💯 实践案例

1. 低代码平台
2. 系统管理
3. 协同办公
4. 唛盟众包-网页
5. 项目管理-网页
6. 项目管理-小程序
   
7. 流程管理

项目分支说明

🐞 交流讨论 、反馈 BUG、提出建议等

1. 快扫描下方左侧微信二维码和我们一起交流讨论吧！（备注 唛盟-mdp 进群）

2. 唛盟微信公众号查看一些基础教程

3. 反馈 BUG、提出建议，欢迎新建：issues，开发人员会不定时查看回复。
4. 参与贡献，请查看贡献指南。

💲 打赏

感谢所有赞赏以及参与贡献的小伙伴，你们的支持是我们不断更新前进的动力！微信扫一扫，赏杯咖啡呗！

🔔商务合作

📢 视频教程(2.**的视频教程)

0.1-唛盟-唛盟生态1+n架构无限扩展、丝滑部署、永不下线

1.唛盟-总体介绍

2.唛盟-工程结构介绍

3.唛盟-工程结构-后端内部结构介绍

4.唛盟-工程结构-前端内部结构介绍

5.唛盟-智能表单-代码生成等模块介绍

5.0-唛盟-前后端开发新手攻略

6.唛盟-用户、权限、菜单、组织管理等模块介绍

7.唛盟-前端工程开发、部署流程介绍

8.唛盟-后端工程开发、部署流程介绍

8.1.唛盟-后端工程开发-mdp-core介绍

8.2.唛盟-后端工程开发-控制层、服务层、dao层开发详细介绍

8.3.唛盟-如何部署单体应用

9.1.唛盟-本地开发前后端如何对接的

9.2.唛盟-前端编译报错如何解决

9.4.唛盟-日志规范及如何快速定位问题

10-唛盟-超强查询接口实现方案、原理解析

10.1-唛盟-复杂查询、多主键crud的实现方案、原理解析

11-唛盟-超强批量更新接口实现方案、原理解析

12-唛盟-多数据源的实现方案、常见问题解决办法解析

13-唛盟-后端国际化多语言版的实现方案、原理解析

14-唛盟-流程整合、原理解析

15-唛盟-分布式数据字典的实现方案、使用示例详解

📢工程介绍

👉唛盟-工程结构介绍

⚠️工程分类：主体工程、基础配套工程、高级配套工程、拓展应用工程、辅助开发工具五大类。
主体工程：本系统业务工程，用于书写本系统相关的业务代码；
基础配套工程：业务工程运行所需的必要工程；如开发底座，系统管理相关功能包
高级配套工程：高级应用，比如需要将业务工程接入oauth2环境、将业务工程发布到cloud环境，才需要下载安装高级配套工程
拓展应用工程： 基于唛盟低代码平台拓展的应用工程，其后端可以单体发布，也可以以微服务方式发布，也可以打成jar被唛盟其它应用引入
辅助开发工具：指开发用到的一些工具

⚠️工程命名规范：业务名称+工程属性
工程属性如下：
-ui: 页面工程
-web: pc端运行的浏览器工程
-backend: 后端服务
-app: 安卓、ios等原生app工程
-uniapp: 基于uniapp开发的应用
-minapp: 小程序
-cloud: 微服务cloud环境
-oauth2: 统一认证中心
-bootstrap: 打包部署工程

唛盟主体工程

唛盟属于前后端严格分离的一套系统，分为前端工程、后端工程两部分

• mdp-lcode-ui-web 唛盟的前端工程,以vue.js为主
• mdp-lcode-backend 唛盟的后端工程，java语言为主

基础配套工程

• mdp-core 启动后端的话必须先安装此工程
  该工程作为所有后端的公共封装，不包含任何的业务功能，仅作为后端系统的技术底座，包含一些公共工具、服务类抽象、dao层抽象等。

高级配套工程

• mdp-cloud-backend 非必须
  该工程作为spring cloud的扩展工程，如果需要将系统发布到spring cloud环境，需要下载该工程重新打包，不包含任何的业务功能，仅作为后端接入cloud环境使用

• mdp-oauth2-backend 非必须
  该工程为统一认证中心，作为spring oauth2的扩展工程，如果需要将系统接入oauth2环境，需要下载该工程重新打包，该工程实现分布式单点登陆；支持微信、支付宝、短信、账户密码等多种登陆方式

开发辅助工具

• mdp-code-generator 非必须 代码生成器
  生成代码两种方式，
  一、使用代码生成器本地工程，好处是代码可以直接覆盖到本地业务工程，避免复制黏贴出错。
  二、如果不需要本地生成代码，也可以在低代码平台在线生成。在线生成代码

拓展应用工程

• 拓展应用工程： 基于唛盟低代码平台拓展的应用工程，其后端可以单体发布，也可以以微服务方式发布，也可以打成jar被唛盟其它应用引入