解决方案打包与发布 (Packaging & Baseline)
在 Aras Innovator 的生命周期管理中，将配置成果（如新建的 ItemType、Form、Workflow 等元数据）从本地开发环境（LDE）迁移到共享测试环境（SDE）、用户验收环境（UAT）直至最终的生产环境（PRD），不能通过直接“拷贝数据库”来完成。
Aras 采用 方案打包系统 (Solution Packaging)，通过把元数据定义转换成符合特定层级结构的 AML（XML 格式）物理文件进行版本控制和迁移。
1. 核心概念：Package Definition
Package Definition (包定义) 是 Aras 打包系统的核心元数据对象，位于管理端 Administration -> Package Definitions 菜单下。
- Package Group (包组)：用于对包内包含的元数据类型进行分类（例如：所有的方法归于
Method组，所有的对象类归于ItemType组）。 - Package Element (包元素)：具体被打包的元数据对象实例。一个 Element 代表一个真实的 Item 记录（比如，某个具体的 Form 元数据）。
2. 打包与命名规范 (Naming Conventions)
为了避免在大型企业联合开发中不同系统、不同功能模块之间的命名发生重叠和覆盖，开发团队必须遵循严格的命名规则：
2.1 包的命名空间规范
- 命名格式推荐使用 Java 风格的反向域名表示法：
[公司标识].[模块名称]。 - 例如：
com.mycompany.plm_base（PLM 基础配置包）、com.mycompany.ecn_enhancement（变更增强功能包）。
2.2 元数据物理文件命名规范
在导出到磁盘后：
- 一个 Package Definition 会对应一个存放目录。
- 目录下会包含一个主清单文件：
imports.mf(Manifest File)。 - 包含一个说明文件：
manifest.xml。 - 实际的元数据会被分类存放在各子文件夹中，扩展名为
.xml，内容为 AML 查询语句，用于在导入时向目标数据库更新或添加该记录。
3. 包依赖分析 (Package Dependencies)
如果 Package A 引用了 Package B 中的元素，在导出时必须在 Package Definition 的 Dependencies（依赖关系） 中添加声明。
导入时的“悬空元数据”报错
例如，你在 Package_B 里创建了一个零件关系类 Part BOM，它的 Related Item 指向了 Package_A 里定义的 Vendor（供应商）ItemType。 如果你没有在 Package_B 的依赖关系中添加 Package_A，在将 Package_B 部署到全新的空白系统时，系统会因为找不到 Vendor 元数据定义而直接中断报错。
- 分析规则：在打包发布前，管理员必须在 Package 界面运行
Dependency Analysis，系统会自动遍历当前包内所有对象的所有属性关联，列出潜在的外部缺失依赖，开发者必须根据提示在元数据中补齐依赖配置。
4. 导入与导出工具的使用 (Import/Export Utility)
Aras 提供了两款独立于网页端之外的命令行/桌面级实用工具：Export Utility 和 Import Utility。
4.1 使用 Export Utility 导出方案
- 启动
Export.exe，输入本地开发环境（LDE）的连接地址与管理员账号（如admin）。 - 在包列表中，勾选你需要导出的 Package Definitions（可以同时导出多个包）。
- 指定本地磁盘上的输出目录。
- 生成产物：工具会自动将数据库中的元数据翻译为 AML 物理文本文件写入本地目录，目录会自动按 Git 标准结构组织，准备推送版本库。
4.2 使用 Import Utility 导入部署
- 启动
Import.exe，连接目标环境（如 SDE 或 UAT 数据库）。 - 选择 Manifest 文件：定位到要导入的 Package 根目录下的
imports.mf文件。 - 选择导入模式 (Modes)：
- Merge (合并，推荐)：如果目标库已有同名对象，执行增量修改或覆盖；没有则新增。
- Recreate (重建)：强行删除目标数据库对应对象并重新创建。
- 点击 Import 运行。工具会读取 manifest 清单，按照正确的依赖拓扑顺序分批向服务器发送 AML 插入/更新事务，并在日志窗口实时打印事务成功或失败的信息。
5. 企业级持续集成与基线发布 (CI/CD Baseline)
在大型项目中，发布流程采用“基线发布管理”：
- 确立基线 (Baseline)：将某一历史节点上所有经过批准并 Merge 到 Git 主仓的代码树文件与包文件归类为一个 Baseline（通过 Git Tag 标记，如
v1.2.0-baseline）。 - 自动构建流水线 (Pipeline)：
- 当检测到发布 Tag 时，Azure DevOps 等流水线会被自动激活。
- 流水线拉起一个 SIT（系统集成测试）实例。
- 自动运行
Import.exe命令行脚本，无须人工干预，直接将 Git 库中的 AML 文件批量部署导入到 SIT 数据库，并在运行结束后执行测试验证，通过后形成最终的分发镜像包。