软件应该以标准的格式来交付

令人深思的经历

曾经历过这样的事情，平台侧要求应用提供满足平台特有格式的交付件，经过多次协商，最终还是应用侧与平台侧一起开会，由平台侧帮助应用侧输出。

另一件事，Kubernetes Yaml以其独特、强大的合并属性能力闻名于江湖。应用侧对Kubernetes Yaml不熟悉，新手想要把环境上的Yaml导出直接作为标准交付件，虽然也行，但是包含了很多噪音，环境上的id、环境上的annotation、时间戳等等。

私有化格式的交付困境

越来越多的软件将自己定位为”平台”，无论是微信、飞书这样的国民应用，还是各类企业级软件。但平台交付的过程中，一个普遍存在的问题是：许多平台要求合作伙伴或第三方开发者使用其私有化的交付格式。这种私有化格式往往存在诸多问题：

• 学习成本高，难以掌握。
• 文档不完善，依赖平台方支持。
• 迁移困难，形成供应商锁定。
• 最终往往仍需平台方投入人力协助。

软件交付应该标准化

软件交付应该使用标准的格式，这有助于降低合作伙伴的接入成本，提高自身的可扩展性，尤其在AI辅助研发的现状下，采用标准的格式更有利于AI理解和生成代码。

交付件	标准格式	使用场景
Java库	Jar包	作为依赖库被其他Java项目引用和集成，需要发布到Maven仓库。
应用镜像	标准镜像包	以容器方式交付，确保运行的一致性。（但如x86、armv8、armv7）的差异依然存在。
应用部署（I层资源已具备）	helm、docker compose	商用场景多用Helm包，单机伪集群/组合方式多用docker compose。
应用部署及I层资源创建	Terraform	需要交付底层基础设施或云服务的场景，如整个应用运行环境。

如果实在要使用私有的格式，可以对标准格式做一些裁剪/扩展（Kubernetes的annotation），将标准格式转化到私有格式。