当前位置：首页 > news >正文

D365财务和运营应用

news 2025/10/6 6:28:05

p1、D365FO优点

1、 Dynamics Lifecycle Services（LCS，生命周期服务），用来 “维护后台”。能干这些事：

管云环境、更新系统版本、配访问权限、方便对接外部工具。

2、用 Visual Studio 写代码，开发时不用连在线数据库，改本地 XML 文件就行；

写的 X++ 代码会转成通用中间语言（CIL），能和 C# 等.NET 语言配合用；

有 “应用生命周期管理（ALM）” 工具，能自动完成代码构建、测试、部署到云端，不用手动传文件。

3、有5 类专用报表

4、靠 数据实体 这个功能，能轻松和其他工具集成：

微软工具：比如连 Power Apps（做轻量应用）、Power BI（做可视化报表），数据直接拉过去用，不用手动导 Excel 再上传；

p2、开发与交付指南

1、开发：只能扩展源码开发，不能修改源码。避免源码更新时发生冲突。

比如，删除了一段用不到的源码，但是系统更新源码时，就需要手动合并此块。

2、两种上传代码给客户的方式

模型文件：包含源代码，适合给那些需要进一步定制的客户。
可部署包：编译后的应用程序包，客户无法看到或修改源代码。
- 你还可以在模型中设置标志，直接阻止该模型被其他人定制改动。

3、好的代码结构

遵循好的软件设计原则（如 SOLID 原则）。
常用起步模式：创建两个模型/包——一个“基础包”用于扩展微软的平台，一个“应用包”用于扩展微软的应用功能。
按变化频率拆分：将经常变动的部分放在独立的模型和包中，便于单独更新。

SOLID 原则对应的 5 个核心原则名称（按字母顺序）如下：

S：单一职责原则（Single Responsibility Principle）

O：开放封闭原则（Open/Closed Principle）

L：里氏替换原则（Liskov Substitution Principle）

I：接口隔离原则（Interface Segregation Principle）

D：依赖倒置原则（Dependency Inversion Principle）

4、关于持续交付（敏捷开发和自动化）

必须拥有“构建环境”
- 这是一个专门的、自动化的环境，用于编译代码、运行测试和生成部署包。
- 重要警告：不要把它当开发机用！这个环境会被定期重置，上面的任何自定义数据或代码都会被清空。
自动化测试策略：金字塔模型
- 底层（大量）：单元测试。这些测试运行快、不依赖特定数据，是质量的基石。
- 顶层（少量）：场景测试（基于任务录制）。这些测试模拟用户操作，但维护成本高，应只用于关键业务流程。
- 核心建议：多写单元测试，少写场景测试。
如何做到“敏捷”？
- 短周期交付：以2周（冲刺）或1个月为周期，每个周期结束时都应具备可交付的、高质量的功能增量。
- 优先处理 Bug：不要让 Bug 堆积起来，这会影响后续开发效率。
测试数据管理
- 准备一个包含所有必要基础数据（如科目表、客户等）的“干净”测试数据库。
- 将这个数据库备份，并分享给所有开发人员和构建环境。构建环境会在每次构建前自动恢复这个备份，确保测试起点一致。

5、关于客户项目实施与环境规划

标准环境配置
- 一个 生产环境。
- 一个 第2层沙盒环境（标准配置，可作为配置、测试和用户验收测试环境）。
“黄金配置”与上线流程
1. 在沙盒环境中完成所有配置和测试，使其达到准备上线的完美状态（即“黄金配置”）。
2. 将此时沙盒的数据库做一个备份。
3. 将代码部署到生产环境，并将在第2步备份的“黄金配置”数据库复制到生产环境，完成上线。
上线后的环境管理
- 你可以购买更多的沙盒环境来满足不同需求，例如：
  - 一个用于日常测试和配置。
  - 一个作为“预生产”环境，用于在应用更新到生产环境前进行最终验证。
- LCS 提供了强大工具来管理环境，如：将生产数据复制回沙盒用于问题排查、将沙盒恢复到某个时间点等。

p3、如何让包可以测试运行，但不生成为可部署包

在 Microsoft Azure DevOps 中，在“生成和发布”页的“生成”下的“所有定义”选项卡上，找到生成定义。单击省略号（...），然后单击“编辑”。
在“变量”选项卡上，请注意，新生成定义具有名为 PackagingExclusions 的变量。
在 PackagingExclusions 变量中，指定一个以逗号分隔的列表，列出不应打包到可部署包中的包名称。

p4、获取代码开发2种情况

情况一：收到的是第三方【模型】（源代码）

场景：第三方以源代码形式（.Model 文件）提供他们的解决方案。

处理流程：

安装与编译：在一个开发虚拟机（VM）上手动安装这个模型。安装后，Visual Studio 中就能看到这些源代码。
纳入版本控制：这是关键步骤。你需要将这些新模型的源代码文件（位于元数据文件夹中对应的包目录下）添加到 Azure DevOps 的源代码管理中并签入。
团队协同：
- 其他开发人员：无需手动安装。只需要从 Azure DevOps 执行 “获取最新版本”，就能自动同步到本地。
- 构建环境（Build VM）：在每次自动构建时，会从 Azure DevOps 获取最新代码，自动编译这些第三方模型，并将其包含在最终生成的可部署包中。

核心好处：保证了所有环节使用的第三方代码都是同一版本，并且经过了自动化流程的编译。

情况二：收到的是第三方【可部署包】（二进制文件）

场景：第三方不提供源代码，只提供编译好的、可直接部署的包（.deployablepackage 文件）。

处理流程：

安装包：在一个开发虚拟机（VM）上，通过命令行工具手动安装这个可部署包。这会将包的二进制文件（运行时包）解压到本地元数据目录。
纳入版本控制：同样关键。找到解压后的包文件夹，将其中的二进制文件（排除 XppMetadata 和 Descriptor 这类设计时文件夹） 添加到 Azure DevOps 中并签入。
团队协同：
- 其他开发人员：无需手动安装包。通过 “获取最新版本” 即可同步这些二进制文件到本地。
- 构建环境：会自动从源代码管理获取这些二进制文件，并直接将其包含在最终生成的可部署包中。
- 重要警告：绝对不要在构建 VM 上手动安装这些包，必须通过源代码管理这个唯一渠道。

核心好处：即使没有源代码，也能保证二进制依赖项在团队和环境中完全一致。

最终成果：一体化的部署包

通过以上两种策略，无论第三方提供的是什么形式的组件，你的自动化构建流程最终都会产出一个 “全能”的可部署包。这个包里面已经包含了你的所有定制代码以及所有依赖的第三方组件。客户或测试环境只需要部署这一个包，就能获得完整可用的解决方案，无需担心复杂的依赖关系。

p5、一体化可部署包

一体化可部署包 指的是一个单一的、完整的软件包，它包含了你的环境中所有非微软的定制内容。这包括你自己的所有定制模型、所有第三方（ISV）的解决方案（无论是代码还是二进制文件），以及必要的许可证。

为什么必须使用一体化包？

消除依赖和顺序问题：不同的安装顺序有时会导致环境行为异常。一体化包一次性安装所有内容，彻底避免了这个问题。
自助服务环境的硬性要求：这是最重要的原因之一。对于自助服务环境，微软使用了容器化技术，每次部署都相当于重建一个全新的环境。如果你只部署了包含“部分”定制内容的包，那么其他没有被包含进来的定制就会在新环境中丢失。只有一体化包能保证新环境是完整的。
简化管理与提升可靠性：管理一个包远比管理多个包并处理它们之间的依赖关系要简单、可靠。

如何创建一体化包？

主要有两种方法：

自动化方式（推荐）：如果你已经建立了持续集成/持续交付（CI/CD） 流水线，那么你的构建环境（Build VM）在每次成功构建后，自动生成的包就是一个一体化包。因为它会从源代码管理中拉取所有模型和二进制依赖，并打包在一起。
手动方式：如果没有构建环境，可以在Visual Studio中手动选择所有需要的模型来创建可部署包。

如何处理特殊情况？

ISV只提供二进制包（没有源代码）：没问题。按照另一份指南（《使用源代码管理管理第三方模型和运行时包》），将这些二进制文件也纳入你的源代码管理。这样，你的自动化构建过程就能将它们一并包含在一体化包中。
ISV许可证：许可证文件也需要被包含在一体化包中。可以通过在Azure DevOps的构建或发布流水线中添加特定任务来实现。

关键要点与行动号召

趋势与强制要求：使用一体化包是云原生开发的最佳实践，并且对于自助服务环境是强制性的。
立即行动：如果你还没有开始这么做，现在就需要开始规划并向一体化部署模式迁移。
检查特定功能：如果你使用了支付连接器或Commerce的相关功能，必须确保这些组件也被包含在你的包中，并有特殊的同步步骤。

p6、自动给模型加版本号

Dynamics 365 财务和运营应用在 “平台更新 6” 后，新增了 “自动给模型加版本号” 的功能 —— 生成部署包时，会把当前的 “生成版本” 写进模型里，方便跟踪代码来源

一、模型版本是啥？怎么看？

模型版本格式：和.NET 程序版本一样，是 4 个数字用点隔开（比如 1.2.3.4），就算多个模型打包，每个模型的版本信息都会保留。
两种查看方式：
1. 在 LCS（生命周期服务）看：进环境 “完整详细信息”→点 “查看详细版本信息”→选 AOS 服务器→展开发布商名字，就能看到模型和对应的版本号；
2. 在系统客户端看：登录系统→点右上角齿轮→“关于”→展开 “加载的包及其模型”→找到对应包，就能看到模型版本。

二、为啥要给模型加版本？—— 版本控制的目的

核心是 “让代码可跟踪，不混乱”：

每次生成部署包，Azure DevOps 会记录这次生成的更改；给模型加版本号后，能直接通过版本找到 “这个模型来自哪次生成”，进而查看这次生成里改了哪些代码；
比如公司有 “夜间自动生成”“测试生成”“正式部署生成”，不同生成的版本号不一样，能轻松区分 “这个部署包里的模型是来自夜间生成，还是正式生成”，避免弄混。