在继续之前，我们假设
-
您已在 accounts.jenkins.io 上创建了 Jenkins 账户
-
您已注册 Jenkins Infra 邮件列表 jenkins-infra@googlegroups.com
-
您已访问我们的票证系统 issues.jenkins.io
-
您已在 IRC 频道：#jenkins-infra 说过“嗨”
基础设施
概述
作为一个独立的开源项目，Jenkins 项目维护着它自己的大部分基础设施，包括支持项目运行的服务。属于“基础设施”的事务可以涵盖从操作虚拟机、容器、配置网络，到开发和维护项目特定的应用程序，以提高 Jenkins 核心和插件开发的效率。
由于我们坚信开源原则，因此我们也将其应用于我们的基础设施。因此，我们认为自己是一个开放的基础设施项目，欢迎所有人学习、分享和贡献。
团队
Jenkins 的基础设施由 Jenkins 基础设施团队维护。该团队由 Jenkins 的贡献者和志愿者组成，他们在自己的可用时间和承担其他承诺的基础上提供尽力而为的支持。我们一直在寻找有兴趣改进 Jenkins 服务并帮助维护这些服务的贡献者。
会议
Jenkins 基础设施团队每周二中午 12:00（UTC 时间）举行一次会议。这是定期安排的会议，用于同步 Jenkins 项目中各种正在进行的基础设施计划。会议对所有感兴趣的人开放。请参阅活动日历了解会议链接。
您可以在 jenkins-infra/documentation 上找到基础设施团队的会议议程和会议记录。
基础设施
资源调配
Jenkins 项目的大部分基础设施运行在 Azure 上，由持续交付基金会赞助。这些基础设施是从 jenkins-infra/azure 仓库使用 Terraform 和 AKS charts 进行资源调配的。
虽然我们努力坚持使用 Azure，但我们仍然拥有由 OSUOSL、AWS、Rackspace 或 CloudBees 等不同组织赞助的机器。
配置管理
基础设施
Jenkins 项目的基础设施通过一个名为 jenkins-infra/jenkins-infra 的 git 仓库使用 Puppet 进行管理和编排。我们还使用通过 jenkins-infra/charts 使用 Helm & Helmfiles 进行编排的 Kubernetes 集群。
监控
基础设施通过 Datadog 进行监控。Datadog 的配置在 jenkins-infra/datadog 上使用 Terraform 自动化。
我们还提供不同的仪表板来分享我们系统的运行状况。
服务
Jenkins 基础设施项目的另一个重要方面是维护我们或第三方提供的所有服务。以下是我们提供和维护的服务的一个不完整列表。
Kubernetes 中的自托管服务
| 服务 | 问题跟踪器 | 仓库和链接 |
|---|---|---|
- |
||
Infra CI - https://infra.ci.jenkins.io/ |
- |
|
Release CI - https://release.ci.jenkins.io/ |
||
Keycloak 身份管理 |
||
LDAP |
||
SSL 证书续订 |
||
插件网站 API 后端 |
||
评分指标 |
||
自托管服务
| 服务 | 问题跟踪器 | 仓库和链接 |
|---|---|---|
代码，通过 GitHub Pages 发布 |
||
VPN |
贡献
我们的基础设施是一个由 Jenkins 社区构建、为 Jenkins 社区服务的开放式基础设施项目。换句话说，这是一个由贡献者驱动的项目。虽然我们无法公开共享所有内容，如秘密、证书等，但我们仍然尽量保持透明，以便每个人都能理解和改进我们的基础设施，而无需特权访问。如果您有任何有助于改进基础设施或引起社区兴趣的想法，请随时提出建议。
为了贡献基础设施项目，我们要求人们遵循以下步骤
Pick up a task => Communicate => Implement => Deploy => Review
领取任务
为了跟踪 Jenkins 基础设施项目需要完成的工作，我们使用 Github 帮助台仓库。如果您想贡献，第一步是在此项目中找到您想处理的问题，将其分配给自己，然后进行沟通（参见 沟通）。
如果您找不到合适的问题，请创建一个新问题并附上清晰的描述
-
原因（要解决的问题是什么 - 高层价值）？
-
什么（您提出什么建议来解决问题）？
-
如何（需要进行哪些技术更改）？
您还可以指定组件，最后，您可以根据下一节的建议进行沟通。
|
优质入门问题
如果您想开始为 Jenkins 基础设施做贡献，您可以在以下页面找到一份“优质入门问题”列表（它们都带有 `newbie-friendly` 标签）：优质入门问题。 |
沟通
在任何实施之前，重要的是要验证首先（是否）仍然需要实施，然后验证过去是否已进行过相关工作。最好的方法是查找类似的问题，在 IRC 或邮件列表中提问。您还可以参加我们的每周会议来讨论和协调更改。
当主题过于宽泛或难以用几句话解释时，我们会撰写一份 IEP 文件，代表“基础设施增强提案”，该文件的目的是解释我们为什么需要某项内容，我们希望如何解决它，以及为什么我们做出了最终决定。最后，一旦您有了您的票证 ID，您就可以开始寻找知识渊博的人。
无论如何，请记住，提供过多的信息总是比提供过少的信息要好，最终您可能就是最适合处理您案例的人。
简而言之
+----------------------------------+
| |
| Pick up or Create INFRA Ticket |
| |
+----+----+------------------------+
| | If no responses after few days
| | promote it on
| | +------------------------------------------+
| | | |
| +--------------------> IRC: Libera Chat #jenkins-infra <----+
| | | | |
| | +------------------------------------------+ |
| | +------------------------------------------+ |
| | | | |
| +--------------------> Mail: jenkins-infra@googlegroups.com <----+
| | | |
| +------------------------------------------+ |
| If the topic is too big |
| |
| +-------------------------------------------+ |
| | | |
+--------------------> IEP: https://github.com/jenkins-infra/iep |--------+
| |
+-------------------------------------------+
实施
一旦就方法达成一致，并在进行任何更改之前，我们要求贡献者遵守以下规则。
这些规则只是我们认为是“最佳实践”的贡献者驱动项目实践，并且可以根据特定的 git 仓库进行调整。
- 规则 #1：一切都在 jenkins-infra 组织下的 git 仓库中。
-
这样，每个人都可以更容易地找到/审查/审计更改并提出改进建议。
- 规则 #2：所有更改都由至少一名常规基础设施贡献者通过 Pull Request 进行验证。
-
这样，我们总会有不同的人理解基础设施的更改。
请注意：非常欢迎非常规贡献者分享他们的专业知识或提出问题，这也有助于发现不一致之处。
代码审查目的
-
让作者和团队了解正在进行的 code 更改
-
发现由测试未涵盖的逻辑或安全问题
-
收集关于代码可读性或效率的改进建议
- 规则 #3：所有更改都在 ci.jenkins.io 上进行测试
-
这样，我们在合并 PR 时会感觉更自信，并避免回归问题。
- 规则 #4：一切都是自动化的。
-
因此，我们只有一个事实来源，并且不会破坏其他人的工作。如果无法做到这一点，则需要进行充分沟通和文档记录（参见规则 #1）。
- 规则 #5：所有更改都遵循 Github 工作流程。
Fork project -> Create Feature Branch -> Open Pull Request -> Ask Review -> Merge