bitzorcas
中EN

Concept

商业交付概览

从产品仓库、NuGet 包、Consumer Solution 到正式 GA，理解 BitzOrcas 的商业交付边界和证据链。

Last updated

商业交付的核心不是“把仓库压缩后发给客户”，而是把产品源码、客户代码和发布证据分清楚。BitzOrcas 用包、模板、许可证和独立门禁建立这条边界。

三个世界

世界包含什么允许的依赖方式
产品仓库Framework、Platform、Profiles、Hosts、Tooling 的完整源码产品内部可用 ProjectReference 集成
Consumer Solution客户拥有的 Host、业务模块和测试通过私有 Feed 使用 PackageReference
发布批次不可变 nupkg、签名、provenance、SBOM、策略证据只能由受控发布与 GA workflow 读取

产品仓库的集成便利不能泄漏到客户项目。模板输出不得引用产品仓库路径，也不得复制 Framework、Platform 或 Licensing 核心实现。

交付链

产品源码
  → build / test / Release publish
  → pack 不可变 NuGet 包
  → 生成 hash / provenance / SBOM / policy evidence
  → 签名和可信时间戳
  → 上传认证私有 Feed
  → 模板生成 Consumer Solution
  → PackageReference restore
  → Runtime License 激活
  → Commercial GA

产品提交

Build / Test / Pack

不可变 packages + provenance + SBOM

签名与可信时间戳

认证私有 Feed

bitzorcas-host 模板

仓库外 Consumer

Runtime License

Commercial GA

切换与观察窗口

每一段解决不同问题：

  • 包目录与 Profile决定“客户应该拿到哪些包”。
  • 模板决定“客户拥有哪部分源码”。
  • Feed entitlement决定“客户有权下载哪些版本”。
  • Runtime License决定“部署实例有权运行哪些能力”。
  • Commercial GA证明“这批包、证据和外部消费结果来自同一可信发布”。

包与 Profile

可发布项目登记在机器可读商业包目录中。Profile 是一组可复用包闭包，不包含重复实现。模板组合把 Profile、Host role、Generator、Endpoint/Job assembly 和 License Feature 一起投影到 Consumer Solution。

Generator 作为 PrivateAssets=all analyzer 直接进入声明的 Host，不能依赖 NuGet 的传递传播。这样生成行为对每个 Host 都是显式、可审计的。

发布列车与不可变性

同一个商业发布批次必须绑定：完整 40 位提交、统一包版本、包集合、每个 nupkg 的 SHA-256、签名者、provenance、SBOM、策略结果和外部 Consumer。只要其中一项变化，就应产生新批次；已经发布的包版本不能覆盖。

变化能否沿用原批次正确动作
只修改发布说明文字取决于证据是否入 provenance保留审计记录并重新验证索引
nupkg 内容或依赖变化不能升版本、重新打包和签名
signer 轮换不能悄悄替换更新可信指纹并产生新证据
SBOM/漏洞结果变化不能忽略重新执行策略门禁
Consumer 模板变化不能新候选批次重新做仓库外消费

“同版本重新上传”会破坏缓存、签名、hash 和客户复现能力，因此不是补发方案。

谁对哪段负责

角色核心责任交付物
框架维护者包依赖、公开 API、Generator 和模板边界可打包源码与测试
Release workflow可重复构建、pack、签名、上传、证据索引不可变 artifact
包平台Feed 可用性、认证、版本不可覆盖HTTPS restore 入口
安全/开源治理signer、漏洞阈值、第三方许可证策略策略证据
商业运营Entitlement 与 Runtime License 签发客户/部署授权
应用交付团队Consumer 配置、数据迁移、切换和回滚目标环境验收

没有任何单一团队可以用“我的 Job 绿了”替代完整证据链。

一个例子：多租户授权平台的真实生成路径

以公开 Profile default-business-multi-authorization（RuntimeAdapter 任选其一）为例。注意边界：当前 15 个 Profile 都只生成 API Host——JobHost、Website 等属于后续独立采用，不能通过参数幻象出来。

  1. 模板把 ProfileChoice 推导为 default-business-multi + PlatformModule=authorization，从对应 ORM 的原生资产树复制；
  2. 只生成 Consumer 拥有的 BitzConsumer.Api Host 壳、Business Starter 业务模块骨架和 Unit/Architecture 两类测试；
  3. AppHost 编排 SQL Server、Schema Migrator、API 与 RabbitMQ，authorization 变体追加授权 bootstrap 与独立持久化身份参数；
  4. Endpoint / DI / ORM Fluent Config 由 analyzer 形态的 Generator（PrivateAssets=all）进入声明的 Host，不经传递传播；
  5. 全部 BitzOrcas.* 从私有 Feed restore 同一 releaseTrain 的包版本；
  6. Profile 的 License Feature 闭包固化为静态要求，本地 Consumer Contract 在四类缓存隔离下验证 restore→build→test→publish。

如果模板生成了 src/Framework 副本，或出现指向产品仓库的 ProjectReference，这不是“方便调试”，而是交付边界失败。

验证机器可读清单

产品仓库中的商业包目录和 Profile closure 是交付事实源，文档不能手写另一份包列表。

Terminal window
# 校验目录、Profile 闭包和项目可打包性。
dotnet test tests/BitzOrcas.Architecture.Tests \
  --configuration Release \
  --filter 'FullyQualifiedName~CommercialPackageCatalogTests'


# 在隔离 Feed 中验证真实 Consumer 能否恢复、构建、测试和 Release publish。
dotnet test tests/BitzOrcas.Framework.ConsumerContract.Tests \
  --configuration Release --blame-hang-timeout 12m

目录测试通过说明声明内部一致；Consumer Contract 通过说明当前候选包可被仓库外项目消费；两者都不等于正式 Feed artifact 已通过 GA。

失败应该归到哪一层

失败所属边界不应采用的“修复”
Restore 403Package Entitlement给所有客户长期共享 Token
Host 报 License UnavailableRuntime License关闭 License gate
某租户功能不可用Tenant Feature修改全局 Runtime License
Consumer 缺包Profile/package closure复制产品源码到客户项目
provenance hash 不一致发布批次身份从当前分支现场重打包
readiness 不健康运行环境只看 /health/live 强行切流

当前状态怎么看

仓库已经实现商业包目录、Profile 闭包、Consumer 模板矩阵、本地 Consumer Contract、Runtime License 契约和 Commercial GA 验证逻辑。正式 GA 仍需商业发布环境提供真实私有 Feed、短期凭据、签名者、SBOM、策略证据和外部 Consumer artifact。

所以正确表述是：“GA 门禁能力已具备，等待真实发布批次输入”，而不是“代码合并后 GA 自动完成”。

交付完成的准确口径

只有目标发布批次同时满足以下条件，才能说商业交付完成：包和证据不可变、正式 Feed 可恢复、签名与策略通过、外部 Consumer 全流程通过、Runtime License 与部署上下文匹配、目标环境 readiness 和迁移完成、回滚条件可执行、观察期没有触发停止线。

若真实 Feed、短期凭据、signer、SBOM 或外部 Consumer artifact 尚未提供，状态应明确记录为“外部前置条件未就绪”，不能把本地合同测试的绿色结果改名为 GA。

本章导读

本章核心导航

100%

滚轮或按钮缩放 · 放大后拖动画面 · 双击切换 100% / 200%