# 标准发布流程

### 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) 提供了一个高质量发行说明的范例。

### 结果背景

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

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

### 已知实例

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

### 作者

David Grizzanti

### 状态

结构化

### 翻译校对

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://patterns.innersourcecommons.org/zh/p/release-process.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.