打包发布
BuildingAI 应用打包发布完整指南。本文档详细介绍如何将开发完成的应用打包成符合规范的标准代码包。打包方式对比
BuildingAI 支持以下两种应用打包方式:| 打包方式 | 适用场景 | 优势 | 特点 |
|---|---|---|---|
| 脚本打包 | 自动化部署 | 自动化程度高,批量处理 | 通过命令行交互操作 |
| 可视化打包 | 手动操作 | 图形化界面,直观易用 | 通过Web界面操作 |
脚本打包
通过命令行工具进行自动化打包,适合CI/CD流程和批量处理场景。前置条件
确保您已完成应用开发,并且代码可以通过编译和测试。操作步骤
1. 进入项目根目录
2. 执行打包命令
3. 交互式配置
终端会出现如下交互界面:
4. 填写版本信息
根据输入指引,依次输入:- 应用标识符:应用的唯一标识
- 目标版本号:要发布的版本号
- 是否重新构建:选择是否需要重新构建插件
如果您的代码包中的版本号忘记修改,不用担心,这个脚本会自动帮您修改为您输入的目标版本号。
5. 等待打包完成

6. 获取打包结果
执行完成后,您可以在项目根目录下的releases 目录下找到刚刚生成的该版本的标准代码包。

自动化集成
可视化打包
打包规范
BuildingAI 对打包后的代码包有严格的目录结构要求,确保插件能够被正确识别和加载。允许的目录结构
代码包中,一级目录下只能包含以下文件和目录:- 完整文件列表
- 必需文件
文件过滤规则
自动过滤的文件
自动过滤的文件
以下文件和目录将被自动排除:
node_modules/.git/*.log.DS_StoreThumbs.db- 临时文件和缓存
目录结构说明
| 目录 | 作用 | 重要性 |
|---|---|---|
.output/ | 构建后的生产文件 | 可选 |
build/ | 编译后的静态文件 | 推荐 |
src/ | 应用源代码 | 必需 |
storage/ | 用户上传文件 | 可选 |
static/ | 静态资源文件 | 可选 |
质量保证
版本管理
版本号规范:遵循语义化版本控制(SemVer)
- 主版本号:不兼容的API修改
- 次版本号:向下兼容的功能性新增
- 修订号:向下兼容的问题修正
代码质量检查
安全检查
安全检查清单
安全检查清单
- 敏感信息清理(API密钥、密码等)
- 依赖安全漏洞扫描
- 代码静态分析
- 权限配置验证
常见问题
打包失败怎么办?
打包失败怎么办?
常见原因及解决方案:
- 编译错误:检查TypeScript类型错误和构建配置
- 依赖缺失:运行
pnpm install安装所有依赖 - 版本冲突:检查package.json中的版本约束
- 权限问题:确保有写入releases目录的权限
如何验证打包结果?
如何验证打包结果?
验证步骤:
- 检查releases目录下的打包文件
- 解压并验证目录结构
- 运行
pnpm install确保依赖完整 - 执行基础功能测试
支持哪些发布渠道?
支持哪些发布渠道?
当前支持的发布方式:
- 本地文件打包
- Git仓库标签
- 内部文件服务器
- 后续将支持更多发布渠道
最佳实践
1. 版本发布流程
2. 自动化建议
CI/CD集成
将打包流程集成到持续集成/持续部署流水线
自动化测试
在打包前执行完整的测试套件
版本控制
使用Git标签管理发布版本
3. 发布检查清单
相关文档
创建应用
学习如何创建新的应用模板
模板结构
了解应用目录结构和规范
应用开发
开发环境搭建和调试指南