Create release-process.md

Author: node

translation/zh/patterns/release-process.md

@@ -0,0 +1,75 @@
+## Title
+
+标准发布流程
+
+## Patlet
+
+如果团队不确定 InnerSource 项目的成熟度，他们可能会犹豫是否采用该项目。为了解决该问题，一致的发布说明和已发布制品至关重要。这些做法展示了对项目的坚定承诺，为用户提振了信心，并向他们保证了对可持续和管理良好的软件的持续承诺。
+
+## 问题
+
+When a team is deciding whether to use an InnerSource project, one of their considerations is whether they can rely on the given project for an extended period. Switching the tools/projects that they are using has a cost, so they only want to make those investments when necessary and has tangible benefits.
+
+It is common practice for Open Source projects to have versioned releases, with notes documenting breaking changes, and new features along with either a published binary or link to a Docker image. This practice may not be as transparent or well documented/visible for InnerSource projects, modules, etc.
+
+InnerSource projects that don't have a published artifact or release process reduces trust. Teams won't know when they can expect the next release, when breaking changes are introduced, etc.
+
+## 上下文
+
+Large organizations produce a lot of internal software, much of which could be reused by teams across the company. Operational tooling, software libraries, and infrastructure as code (IaC) modules are common examples of this type of software. Most large organizations, however, don't publish internal software to be consumed by other teams in the company. This can occur either because they are to busy to provide documentation or don't realize the projects value to others.
+
+An internal or public source repository should be available where source code is stored, but teams lack a process for making software consumable by outside teams.
+
+As an organization grows and more internal software is written, the value of this pattern grows.
+
+## 约束
+
+### 对于没有中心化 CI/CD 系统的组织来说很困难
+
+For organizations that don't provide engineers a centralized CI/CD system, automating a build and release process can be challenging. The team may need to stand up their own tool (Jenkins, Drone, etc). Without a CI/CD system, builds and release notes can still be produced, however, it may require a local build of the software and manual upload to whichever tool is hosting build artifacts.
+
+### 增加了发布发行说明的负担
+
+In addition to building your source code, writing release notes can be tedious without the ability to auto-generate a list of git commits. This would be left for someone to do manually, in addition to writing more high level details on a release.
+
+### 没有位置来托管制品增加了难度
+
+If a company does not provide a centralized location for storing build artifacts (jars, npm modules, etc.) and docker images, engineers may be left deciding for themselves where is appropriate to store versioned software. Tools like GitHub provide this for you, however, if a company is not using one of these popular tools, this could pose a burden.
+
+## 解决方案
+
+By providing clear **release notes** and a published artifact you increase people's confidence that you are publishing a quality product that they can rely on.
+
+The following are key elements to achieve this:
+
+- A CI/CD pipeline is located within your repository that [automates the release process](https://opensource.guide/best-practices/#use-tools-to-automate-basic-maintenance-tasks)
+- Build artifacts are generated by the CI/CD system (binary, docker image, jar, etc)
+- Releases are clearly labeled and tagged with [semantic versioning](https://github.com/semantic-release/semantic-release)
+- Releases include notes on New Features, Bug Fixes, and any "Breaking Changes"
+
+A good example of quality release notes can be found [here](https://github.com/jaegertracing/jaeger/releases).
+
+## 结果背景
+
+Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
+接触到您项目的团队会看到发布的发布说明，并对您的工具充满信心。发布的工件也会使您的产品使用起来更简单、更快捷。像这样定义明确、清晰可见的流程还有助于跨团队协作和新的贡献者。他们可以确信自己的贡献会在合理的时间内发布，并有明确的使用路径。
+
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+发行说明也是[表扬参与者](raise-participants.md)的绝佳机会！众所周知，对于希望参与项目的新人来说，[文档是极其重要的](base-documentation.md)。表扬外部队友的贡献，包括文档和发布说明，是培养社区和扩大用户群的好方法。
+
+## 已知实例
+
+* Comcast （多个项目）
+* GitHub （多个项目）
+
+## 作者
+
+David Grizzanti
+
+## 状态
+
+结构化
+
+## 翻译校对
+
+* **2022-12-08** 翻译[Chris杨振涛](https:github.com/node)