DevOps制品管理：深入探索一方、二方与三方组件的生产、消费、分发与协同机制

“如果把"DevOps流水线"比做工业生产中的流水线，那么“DevOps制品”就相当于工业生产中的传送带上的“原材料”，“半成品”和“成品”。工业上流水线提升了生产的自动化水平，但如果传送带上一个“残缺的物料”，那么最终交付的成品质量也无法保证。

之前一篇文章《聊聊DevOps制品管理-不止是存储制品这么简单》已经全方位介绍了和制品有关的知识点，不过没有提到制品的分发/协同/生产/消费等场景，结合最近的实践，总结下心得。

一方/二方/三方组件

在软件开发、供应链管理以及技术合作等领域中，我们常常会听到“一方组件”、“二方组件”和“三方组件”的说法。这些术语通常用于描述组件或产品的来源以及它们与主体项目或系统的关系。

1. 一方组件：一方组件通常指的是项目或产品自身开发或生产的组件。这些组件是项目团队内部直接控制和维护的，通常是项目或产品的核心部分。例如，一个软件开发项目中，由项目团队自行编写的核心代码库，就可以被视为一方组件。
2. 二方组件：二方组件是指由由另一个团队或公司提供的库、框架或中间件。
3. 三方组件：三方组件是指由第三方供应商或开源社区提供的，并广泛用于多个项目或产品的组件。这些组件通常是现成的、标准化的，并且可能已经被大量用户或项目所验证和使用。

这些概念可能大家很容易理解，可是如果把他们带入实际研发过程实践呢？是否真的清晰？某些情况下，他们之间的边界似乎很模糊。

比如一方组件/二方组件，由于生产关系（生产者-消费者），访问权限（私有-共享），面向的场景不同，动态的在变化。

制品协同/分发的复杂性

当你深入业务后，会发现涉及制品的场景至少十几种起步，特别是规模大的组织和团队。如图所示，主要可能涉及以下场景：

• 开源组件引入机制
• 开源制品代理
• 日常构建制品
• 业务团队之间相互依赖
• 业务团队依赖基础平台团队，分发共享
• 业务团队自己开发的服务/SDK
• 团队分布在不同城市/国家
• 制品晋级
• 制品发布交付，客户或客户环境在不同区域

总结

如下图，如果以下因素叠加在一起，制品的管理难度成几何级递增，看着都头大，是不是？

当然，我只是把可能的复杂情况都考虑在了一起，如果是几十人规模、制品规模不大、团队间依赖不大等，难度会变小。

个人觉得，往往组织架构顶层的设计优化（比如减少异地合作，控制团队数量避免多线依赖），会降低业务流程的复杂度。当然，现实中确实存在很多复杂性，那么下面提供我的思路。

解决思路？

1. 全面梳理业务场景，识别制品的生产者和消费者分别是谁，明确依赖关系
2. 各种制品如何流转的？
3. 定义制品的管理规范，统一用词和术语，明确仓库归属和用途 （这个是基础底线）
4. 提高基础设施（存储/网络等）性能
5. 选择好的制品管理工具（PS: 前面这些想清楚是最重要的，工具是最后考虑的）