版本修订
版本 | 作者 | 时间 | 描述 |
---|---|---|---|
0.22 |
Lang |
2024-04-08 |
提醒模块文档(站内信功能) |
0.21 |
Lang |
2023-11-13 |
前端命名语义 |
0.20 |
Lang |
2023-11-09 |
2.0版本文档 |
0.19 |
Lang |
2023-10-25 |
工作流功能升级 |
0.18 |
Lang |
2023-09-07 |
自定义表单、办公协同(ONLYOFFICE) |
0.17 |
Lang |
2023-09-04 |
列操作定制 |
0.16 |
Lang |
2023-08-29 |
上传/下载详解 |
0.15 |
Lang |
2023-08-15 |
CRUD实战 |
0.14 |
Lang |
2023-07-20 |
前端基础教程 |
0.13 |
Lang |
2023-06-04 |
AOP分流器文档 |
0.12 |
Lang |
2023-05-02 |
Agreed Metadata Specification |
0.11 |
Lang |
2023-04-17 |
前端基础 |
0.10 |
Lang |
2023-03-26 |
附件、文档管理 |
0.09 |
Lang |
2023-03-23 |
工作流引擎配置 |
0.08 |
Lang |
2023-03-22 |
Zero Extension详细介绍 |
0.07 |
Lang |
2023-03-20 |
模块化配置/文档修订 |
0.06 |
Lang |
2023-03-16 |
Qr查询引擎(前后端) |
0.05 |
Lang |
2023-03-11 |
配置/实施规范中的权限管理 |
0.04 |
Lang |
2023-02-22 |
前端样式规范补充 |
0.03 |
Lang |
2023-02-14 |
前端结构规范补充 |
0.02 |
Lang |
2023-02-12 |
动态建模平台一键式部署修订 |
0.01 |
Lang |
2023-02-07 |
起草基本云平台规范 |
Chapter I: 环境标准
1. 飞翼零式
1.1. 时间线
1.1.2. 项目结构
新版Zero整体结构如:
项目 | 说明 |
---|---|
|
根项目:POM管理、版本管理、文档管理。 |
|
内含 AMS(Agreed Metadata Specification)接口设计和规范定义,作为最底层跨框架基础功能规范。 |
|
原 Zero Core 核心框架,包含内置组件、功能函数、编排器,为上层容器提供环境支撑,新版还引入了OSGI规范。 |
|
Web容器,可选择三种方式运行:单机运行、OSGI插件运行、云环境运行。 |
|
Infix Architecture 的各种功能插件,对应旧版 |
|
Zero Extension 扩展插件,对应旧版 |
|
动态建模专用外置插件,如 Oracle、MySQL 等,基于 MBSE 的核心插件体系。 |
|
入口程序,可选择:最小环境运行、单点脚手架环境、继承专用POM库。 |
1.2. 设计哲学
如何打造一个零开发、零测试、零运维的系统?也许未来就来了、也许永远都做不到。 作者吐槽:本章节有打广告的嫌疑! |
1.2.1. 均衡工作量
面相开发、测试、运维的均衡工作量框架。
一个系统从开发到最终上线落地,Zero秉承均衡 开发、测试、运维 三大主体角色工作量的核心理念,解决企业在交付项目过程中开发人员只关注于交付的陋习,软件工程本质是以 工程 为目的体系化解决方案,根据实战经验,让开发人员把目光聚焦到:快速交付、工程实战 上,并非以 编程 为中心的战场。从之前项目的经验可以知道,运开测是最注重团队模式的三个点,传统开发模式中重开发,轻测试、运维,很多工程师都抱怨开发不管不顾,到最后形成 运维、测试、二开 的灾难(这种形态在大量中小型企业中比比皆是)。
1.2.2. 建模为主
以建模为主战场的技术框架。
Zero最新版基于 MBSE
理论,以建模为中心打造稳定、可成长、自管理的系统(已渗透到工业领域)。Zero从最早的版本中 代码驱动、到 CMDB 产品的 配置驱动、以及最新版的 数据驱动,整个过程都在强调一个主题:建模。一个完整的系统,模型是设计最复杂的部分,也是抽象层次最高的实现部分,目前Zero已经可以支持多种不同的建模方式(静态建模、混合建模、动态建模),也为企业应用、平台应用、工业应用提供了基础土壤,本教程中所有的开发技能、实战经验都围绕建模展开。
1.2.3. 成长型系统
一个无痛迁移、升级、扩展的柔性框架。
为什么均衡运开测三个角色,因为很多时候开发人员缺了一个执念:所有交付的项目、产品都只是一个过程形态,并非最终形态,那些交付了不再改的系统只是自我安慰罢了。 所以 Zero 框架的设计中很重头戏的一部分是面向各种不同的业务需求变化,您可以说它不是一个纯技术框架,但从目前交付的项目看起来,它拥有着面向新需求快速交付实施的基础。不论是内部框架标准化、外部集成标准化,所有的努力实际都在将目前固化的软件模式、设计范式抽象出来形成标准化模块以驱动后续新业务的扩展。
1.2.4. 数字化体系
以制度、流程、规范、工具为核心的体系化框架。
数字化转型对中小企而言,更多场景并非直接复制大公司的成熟解决方案,而是要基于自身的土壤打造符合企业自身发展的合理的解决方案,如何降低企业在营运过程中的成本,提高管理效率才是真正意义上的体系化解决方案,工具只是其中一部分(包括 Zero 打造的系统也只是整个闭环中的一个阶段)。但是工具要为管理赋能,一些待验证的策略、想法都属于 在路上 的状态,那么如何使用一个工具去帮助企业快速、小成本验证这一切,并对企业提出相关整改项,也是Zero的硬核部分,目前Zero在银行、证券领域中的应用就在扮演这样一个角色,配合制度、规范、流程的落地。
2. 环境要求
最新版本中,核心框架的 |
2.1. 默认HOST
Zero框架中为了方便远程本地协同开发,以及各个团队成员之间协同开发不牵涉配置文件的冲突修改,您可以优先在开发环境(包括生产环境)中配置如下域名映射:
域名 | 默认地址 | 含义 |
---|---|---|
|
|
数据库访问专用地址 |
|
|
后端专用地址(目前版本后端地址使用的是 |
|
|
前端专用地址 |
|
|
(保留)集成配置专用地址 |
|
|
文档服务器 地址( ONLYOFFICE )专用 |
2.2. 后端开发
分类 | 版本 | 执行命令 | 用途 |
---|---|---|---|
运行时 |
17+ |
java |
下载,Java环境 |
运行时 |
3.2.0 |
ruby, gem |
下载,推荐AsciiDoc使用Ruby方式安装 |
运行时 |
2.37.1+ |
git |
下载,MacOS中XCode自带 |
运行时 |
6.5 |
tiup |
下载,TiDB命令 |
2.3. 前端开发
分类 | 版本 | 执行命令 | 用途 |
---|---|---|---|
运行时 |
20+ |
node, npm |
下载,NodeJS环境 |
构建 |
1.22.19 |
yarn |
(npm)直接安装,前端主构建工具 |
构建 |
5.75.0 |
webpack |
略 |
框架 |
5.2.0 |
- |
Ant Design主界面库 |
框架 |
2.3.54 |
- |
Ant Design Pro企业框架主库 |
框架 |
4.2.9 |
- |
Ant G2图表库 |
框架 |
2.3.0 |
- |
Ant G6拓扑图、树图、脑图库 |
框架 |
11.3.1 |
- |
BPMN工作流前端专用库 |
框架 |
18.2.0 |
- |
React主框架库 |
框架 |
6.8.1 |
- |
React-Router专用库 |
框架 |
16.0.1 |
- |
React Dnd拖拽主库 |
运行Zero UI请将Chrome浏览器升级到最新版 |
2.4. 运维部署
分类 | 版本 | 执行命令 | 用途 |
---|---|---|---|
构建 |
3.8.x+ |
mvn |
下载,Maven环境 |
构建 |
1.0.0-m4 |
mvnd |
下载,并行Maven环境(自带Maven 4.0) |
构建 |
7.6+ |
gradle |
下载,Gradle环境 |
容器:运行时 |
20.x |
docker, docker-compose |
下载,容器运行时,新版自带K8S单节点集群环境 |
容器:镜像工具 |
1.8.5 |
packer |
下载,镜像工具,Maven可使用插件直接打包镜像 |
自动部署 |
2.14.2 |
ansible |
下载,应用配置自动部署工具 |
自动部署 |
1.3.7 |
terraform |
下载,基础设施自动部署工具 |
2.5. 文档管理
分类 | 版本 | 执行命令 | 用途 |
---|---|---|---|
文档 |
4.0.x |
jsdoc |
(npm/yarn)JavaScript文档生成 |
文档 |
1.2.2 |
live-server |
(npm/yarn)文档服务器 |
文档 |
- |
dash |
(npm/yarn)标准文档皮肤工具 |
文档 |
2.0.18 |
asciidoctor |
(gem)AsciiDoc文档生成工具 |
3. 流程管理
3.1. 开发流程
3.1.1. 流程图
开发流程走开源社区普遍的Fork流程,整体流程图如下:
整个环境中包括两种PR
-
Dev PR / develop分支
:从开发人员Fork分支中直接提交PR到 develop 分支的PR,develop 分支可配置到测试环境中直接提供给测试人员测试。 -
Release PR / master分支
:从 develop 分支提交同库PR到 master 分支中。
develop 分支和 master 分支追加保护功能,锁定之后不允许任何形式的 push 动作直接修改分支中的内容,仅走PR流程可更改两个分支中的代码。 |
3.1.2. 操作步骤
操作流程参考如下步骤:
-
在远程环境创建Fork(手工操作),Fork之后拿到自己的分支代码路径(如:https://gitee.com/account/xc.git)
-
使用git命令从远程个人账号中下载代码
$ git clone https://gitee.com/account/xc.git
-
在本机项目中运行命令添加远程引用(引用名推荐:upstream):
$ git remote add upstream https://gitee.com/silentbalanceyh/xc.git
-
(上述三步执行完成后就搭建好了本地代码整体环境)提交代码流程:
$ git add . $ git commit -m "您的备注信息" # 该步骤会提交代码到您自己的Fork分支:https://gitee.com/account/xc.git $ git push
-
代码提交之后可在线提交PR到 develop 分支中,Code Review之后执行合并。
-
更新代码流程:
# 注意更新代码是从upstream中更新(develop分支):https://gitee.com/silentbalanceyh/xc.git $ git pull upstream develop # 此步骤的目的是保持最新代码推送到自己Fork分支中 $ git push