如何在项目和团队之间共享和版本化协议缓冲区（proto）接口？

Posted 2023-02-19

【中文标题】如何在项目和团队之间共享和版本化协议缓冲区（proto）接口？

【英文标题】：How to share and version protocol-buffers (proto) interface across projects and teams?

【发布时间】：2018-10-10 05:59:37

【问题描述】：

我正在开展一系列 Python 项目，其中涉及通过 gRPC 的各种服务向其他开发团队 (C++/Python) 提供数据。在此计划开始时，所有文件都包含在服务器项目中，包括 proto 文件。顺便说一句，我使用https://semver.org/ 对我的项目进行版本控制。

然后我开始实现客户端/API 库，因此我将 Proto 文件/生成的代码移动到客户端项目。我还使用 Python 包使服务器依赖于客户端库。

由于我的环境（无 Docker）的性质，服务器被打包在 RPM 中，而客户端生成两个工件 1）可以为 C++ 项目静态链接的 RPM，2）可以上传的 Pypi 包和通过 Pypi repo 下载。服务器通过 PIP 下载 Pypi 依赖项。

我遇到的问题是客户端/API 库上的 SemVer 给出了错误的含义，因为这将原型接口的版本和实际的客户端版本联系在一起。这是一个问题，因为如果客户端库中存在强制版本号发生变化的错误，那么当这是不真实的时，这将给出原始接口已更改的印象。

此时，我开始认为我应该有第三个项目，它只包含 proto 文件和生成的代码。但是，每次我需要实现一项新服务时，这将导致我的 git repo 中的一个小项目（3x）爆炸，或者我应该将所有原型组合在一个项目中。

如果有任何关于如何共享 proto 文件同时保留我的版本号后面的语义的建议或意见？

【参考方案1】：

管理通用原型的 Git 子模块可以解决您的问题。

当您定义一个子模块时，您确定这部分代码对于所有指向该模块的 repo 都是通用的。

您的子模块实际上也指向提交。因此，如果您的模块（原型模型）有更新，您将不得不手动将更新拉入您的业务代码。

另一方面，如果你交付了一个bug，如果你不更新子模块，你就不会重新交付proto。

【讨论】：

感谢您的建议，如果我拥有所有“客户”存储库，这是一个好主意，但是这可能很快成为跨不同团队存储库的许可噩梦。