## Title

标准发布流程

## Patlet

如果团队不确定 InnerSource 项目的成熟度，他们可能会犹豫是否采用该项目。为了解决该问题，一致的发布说明和已发布制品至关重要。这些做法展示了对项目的坚定承诺，为用户提振了信心，并向他们保证了对可持续和管理良好的软件的持续承诺。

## 问题

当一个团队决定是否使用 InnerSource 项目时，他们的考虑因素之一是他们是否可以长期依赖于该项目。更换他们正在使用的工具/项目是有成本的，因此他们只希望在必要时进行这些投资，并获得切实的收益。

开源项目的通常做法是按版本发步，并在发行说明中记录破坏性变更和新功能，同时发布二进制文件或 Docker 镜像链接。对于 InnerSource 项目、模块等来说，这种做法可能不那么透明，或没有很好的文档化/可见性。

缺乏明确的发布制品或规范的发布流程的 InnerSource 项目往往会削弱团队间的信任。在这种情况下，其他团队难以预知下一个版本的发布时间，也无法准确把握可能出现的破坏性变更。

## 上下文

大型组织会生产大量的内部软件，其中很多软件都可以被整个公司的团队重复使用。运维工具、软件库和基础设施即代码（IaC）模块就是这类软件的常见例子。然而，大多数大型企业不会发布内部软件供公司其他团队使用。出现这种情况的原因可能是他们太忙，没有时间提供文档，或者没有意识到项目对其他人的价值。

应该有一个内部或公共代码库来存储源代码，但团队缺乏一个让外部团队使用软件的流程。

随着组织的发展和更多内部软件的编写，这种模式的价值也在增加。

## 约束

### 对于没有集中式 CI/CD 系统的组织来说很困难

对于没有为工程师提供集中式 CI/CD 系统的组织而言，自动化构建和发布流程可能具有挑战性。团队可能需要建立自己的工具（Jenkins、Drone 等）。在没有 CI/CD 系统的情况下，仍然可以制作制品和发行说明，但可能需要在本地构建软件，并手动上传到托管制品的工具。

### 增加了发布发行说明的负担

除了构建源代码之外，如果无法自动生成 git 提交列表，编写发行说明可能会很枯燥。除了编写更多发布细节之外，还需要其他人手动完成。

### 没有地方来托管制品增加了难度

如果公司没有提供一个集中位置来存储制品（jar、npm 模块等）和 docker 镜像，工程师可能需要自己决定在哪里适合存储各版本软件。 GitHub 等工具可以提供此功能，但是，如果公司不使用这些流行工具之一，这可能会造成负担。

## 解决方案

通过提供清晰的**发行说明**和已发布的制品，可以增强人们的信心，让他们相信你发布的是值得信赖的优质产品。。

以下是实现这一目标的关键要素：

- 代码库中包含一个 CI/CD 流水线配置，可[自动化执行发布流程](https://opensource.guide/best-practices/#use-tools-to-automate-basic-maintenance-tasks)
- 由 CI/CD 系统来生成制品（二进制、docker 镜像、jar 等等）
- 发布的版本有清晰的标签，和[语义化的版本标记](https://github.com/semantic-release/semantic-release)
- 发布内容包括新功能说明、错误修复和所有的“破坏性变更”。

[这里](https://github.com/jaegertracing/jaeger/releases) 提供了一个高质量发行说明的范例。

## 结果背景

接触到您项目的团队会看到已发布的发行说明，并对您的工具充满信心。已发布的制品也会使您的产品使用起来更简单、更快捷。像这样定义明确、清晰可见的流程还有助于跨团队协作和新的贡献者。他们可以确信自己的贡献会在合理的时间内发布，并有明确的使用路径。

发行说明也是[表扬参与者](praise-participants.md)的绝佳机会！众所周知，对于希望参与项目的新人来说，[文档是极其重要的](base-documentation.md)。表扬外部队友的贡献，包括文档和发布说明，是培养社区和扩大用户群的好方法。

## 已知实例

* Comcast （多个项目）
* GitHub （多个项目）

## 作者

David Grizzanti

## 状态

结构化

## 翻译校对

* **2024-10-08** 翻译[Chris Yang](https:github.com/node)
* **2024-10-12** 校对[姜宁](https://github.com/willemjiang)
