如何在詹金斯组织乔布斯？

Question

我的任务是设置自动化部署，经过一番研究，我决定让詹金斯（Jenkins）完成工作。在此之前，除了听到这个名字，我对詹金斯的知识几乎为零。除了最近两周我学到的知识之外，我对Devops并没有真正的了解。没有正式的培训，没有实际的书籍，只有Google搜索。

我们没有运行完整的/经典的CI / CD流程；这是一个商业决定。基本要求是：

• 源代码将存储在GitHub中。
• 请求必须经过同行批准。
• 拉动请求必须通过build / unit / db部署测试。
• 对特定分支机构的承诺必须触发对相关特定环境（生产，暂存或开发）的部署。

我尝试支持的基本功能涵盖了（我目前所看到的）两个单独的过程：

• 创建拉取请求时，将构建应用程序，运行单元测试，并测试db部署。状态信息必须传递到GitHub。
• 在提交到三个特定分支（主，暂存和开发）之一后，应构建应用程序，并将其部署到三个环境（生产，暂存和开发）之一。

我设法将完成第一项任务的管道拼凑在一起。我正在使用通用的Web挂钩触发器，并使用存储在源代码控制中的声明性管道来手动处理所有步骤。到目前为止，它的运行情况还不错，经过多次黑客攻击后，我对它的形状感到非常满意。

我现在要开始进行自动部署。

我的实际问题。

简而言之，我如何将其分解为詹金斯的乔布斯？

在我看来，要创建1、2或4个工作：

• 一个人治好一切

在我看来，这不是最理想的选择，因为管道将包含相对复杂的条件逻辑，并且取决于作业是由请求请求触发还是由提交触发，将运行不同的阶段。历史数据将被污染到几乎无用。

OR

• 一项处理拉取请求的工作
• 一项处理提交的工作

将在所有环境中混合用于部署的历史数据。我有点担心我最终在存储库中会得到> 1 Jenkinsfile。尽管我没有技术上的理由不能拥有超过1个Jenkinsfile，但是我看到的每个示例都使用一个文件。可以在存储库中使用> 1个Jenkinsfile（Jenkinsfile_Test和Jenkinsfile_Deploy）吗？

OR

• 一项处理拉取请求的工作
• 一项处理提交给开发人员的工作
• 一项用于处理暂存的工作
• 一项处理生产提交的工作

这似乎比以前的选项有一些好处，因为部署到每个环境的历史数据不会相互交叉污染。但是现在我们已经超过了超过1个Jenkinsfile（可感知）的限制，我最终将得到（Jenkinsfile_Test，Jenkinsfile_Deploy_Development，Jenkinsfile_Deploy_Staging和Jenkinsfile_Deploy_Production）。这种方法还带来了额外的复杂性（共享库中的通用代码）或复制/粘贴代码重用，我当然想避免。

我的主要目标是让我自己以外的其他人来维护它，因为Bus Factor。一个真正的Devops / Jenkins人员将不得不整天更新/管理它们，我强烈希望他们不要遭受我的无知之苦。

我进行了无数次搜索，但没有找到任何可以提供我所需指导的内容。搜索最佳实践时，不会处理> 1个Jenkinsfile，而只关注单个管道的内容。

Answer 1

经过进一步研究，我找到了对我的核心问题的答案。这可能不是绝对正确的答案，但对我来说很有意义，可以满足我的需求。

虽然从技术上讲项目中可以有1个以上的Jenkinsfile，但似乎与最佳实践不符。

最佳实践似乎是为每个Jenkins文件创建一个单独的存储库，该存储库将1：1与Jenkins中的Job映射。

为了支持我的特定用例，我从主要的源代码存储库中删除了Jenkinsfile。然后，我创建4个新存储库：

  

项目 _Jenkinsfile_Test
  项目 _Jenkinsfile_Deploy_Development
  项目 _Jenkinsfile_Deploy_Staging
  项目 _Jenkinsfile_Deploy_Production

每个存储库都包含一个Jenkinsfile和一个readme.md，从理论上讲，它们包含有用的信息。

通过这种分离，我可以很好地了解整个测试运行的历史成功/失败，以及分别部署到每个环境的情况。

以后我很可能会创建第五个存储库：

  

项目 _Jenkinsfile_Deploy_SharedLibrary

最后一个存储库将包含在四个“核心”管道之间共享的管道代码。一旦“核心”管道正常启动并运行，我将考虑将我可以重构的内容重构到该共享库中。

我目前不会接受自己的答案，希望能有更多答案。

Answer 2

这是一个建议，我会根据我上一份工作的经验来尝试满足您的要求。

• Job1：在master或您的主要dev分支上的每次提交上构建并运行单元测试（每20分钟检查一次，或检查是否适合您）；这项工作通常会很快发现编译和单元测试问题
• Job2（可选）：如果Job1的最后一次运行成功，则每晚运行集成测试和各种静态代码检查（例如clang-tidy，valgrind，cppcheck等）；这项工作通常可以找到很多东西，但是可能要花很多时间，所以让它只在晚上运行
• Job3：为发布分支构建和测试每个拉取请求；因此您可以在pull请求中获得一些信息（如果信息足够成熟，可以合并到发行分支中）
• Job4：在发行分支上的每次提交上都部署到适当的环境；在开发和测试阶段，如果有测试，您可能会触发更多测试

因此Job1，Job2和Job3应该一直运行。如果对您的发布分支的拉取请求得到了质量检查的批准（即检查正常并且测试成功）并合并到发布分支，则Job4会自动完成部署。

如果您希望仅手动触发Job4，则取决于您的要求和开发过程。