一个Jenkinsfile还是多个？

Development
> Build artefact > Build Docker image
> Deploy Docker container to testing > tests & QA
> deploy to staging > have client check it
> deploy to production

#1 楼

这确实取决于个人喜好。

您可能不知道的另一个工具是管道共享库。这些使您可以快速编写自定义的Pipeline步骤或分解常见的Pipeline代码，而无需在Java中编写Jenkins插件。

在多个Pipeline作业和共享库之间，有很多方法可以拆分作业的代码并没有一个正确的答案。我的一个建议是确定流程中哪些步骤是“基本的”-也就是说，您设想admins / ops / devs / etc的最小步骤是什么。可能需要自己运行？然后，每个“原子单元”都应成为自己的工作。例如，假设您正在自动化部署过程，并且您的过程在一般意义上如下所示：


构建
部署到开发
部署到产品

然后我将创建三个作业，每个项目要点一个。这为您提供了一些不错的优势：


您可以单独重新运行每个作业，以防万一失败，而不必从头开始重新启动整个过程。部署到产品失败？您只需要重新运行部署到生产作业即可。您不需要重建或重新部署到开发。
该过程的每个阶段都被分离出来，因此您可以查看它成功或失败的频率。您过程中的某些阶段可能比其他阶段更健壮或更脆弱；这种分离使您可以深入了解。
这种抽象级别使非操作人员易于执行操作任务（如果这是您希望/组织需要的操作）。当一切都是整体时，非操作人员唯一能做的就是从头开始运行整个过程。当一切分解成微小的工作时，您需要熟悉操作的知识才能知道哪些零件以什么顺序运行。通过将您的工作分成独立的，易于理解的，适当大小的块，非操作人员只需按一个按钮即可启动自动化操作流程。

#2 楼

走过类似的道路，这是我的建议：

按功能划分任务；构建与部署不同，发布与众不同。您可以得到更详尽的信息，但是现在让我们坚持基础知识...

其次，如果要考虑允许谁执行某些操作，则可以按团队将这些功能分开（开发人员，测试和发布）。

构建管道：


这可能是您的开发团队。
检查源代码，进行编译和打包的一项工作。
也许对此包进行单元测试
也许将代码发送给SonarQube进行分析
如果成功，则发布此构建工件在某些地方，例如Artifactory / Nexus
，只要有人将其推送到仓库，我都会自动运行此作业。另外，我有一些规则会限制基于分支的行为（我真的不想为每个分支发布构建单个功能分支，但始终是发布分支）

部署管道： >我们是否要部署到开发服务器？还是要进行Test / Pre-rel / Live？
创建一个deploy-dev作业和一个deploy-prod作业。两者都使用相同的Jenkinsfile
谁有权执行此操作？
我们要部署什么？这是Artifactory中可用的工件的下拉列表。
我使用JobDSL生成使用同一管道的多个作业。一个用于dev / test / pre / live。您可以首先使用适当的部署目标/用户手动创建这些作业。

上面的内容使我可以编写针对性强且特定的管道，但仍为团队提供了日常工作所需的灵活性。开发和测试是自助服务。只有发布团队有权部署到预发布/正式发布。

其他管道：


一旦工作，您可能会发现可以跳动服务器（团队自助服务）并在Nexus / Artifactory中将快照/分段/ RC存储库升级为黄金存储库等的工作。
您是否正在使用git -流？如何创建/完成发布/功能分支，改进Maven版本，整理陈旧的分支，执行集成构建等工作。所有的好玩的事情。

希望这会有所帮助。

#3 楼

我最近建立了一个构建测试-发布-部署-回滚管道，并为一个或多个管道的问题苦苦挣扎。我决定在单个管道上执行所有任务，原因是很容易去一个地方，并通过输入参数告诉管道您要做什么。当时这似乎是个好主意，但自发布以来，我已经闻到了一些缺点：


给定管道构建的成功或失败并不意味着应用程序代码是一定不好。例如，由于管道代码中的错误，我们曾导致生产失败，但这并不意味着应用程序构建不佳。但是“构建状态徽章”在我们的自述文件中显示Failed。这不是真的（我们的看法）。
它更复杂。有多个通过管道的路径，由参数值确定。
公然地打破了单一责任原则和最小惊讶原则。为了保护用户，它不一定会根据我内置的某些规则执行预期的操作。使用更简单的管道，出错的机会就会更少。
我们的组织还没有发展成真正的持续部署，因此总会有一个延迟，有人按下“部署”按钮，甚至进行质量检查。我们可能会早些而不是晚些时候将CD移入质量保证体系，但是我们必须证明所有这些方法的安全性和可靠性，才能使上层人士满意CD投入生产。分隔功能明确的管道。

我现在正在为同一类型的服务构建另一个管道，并且我计划重构以使用单独的管道来构建和部署-与上面列出的@jayhendren相同：


构建，测试（目前几乎不存在），发布工件


我正在尝试构建食谱，以启动临时计算机以进行部署，从而为开发人员提供独立的测试沙箱。


部署到质量检查
部署到Prod

值得一提的是，我们绝对在使用Multibranch管道，至少用于构建管道，并且尽可能使用声明性语法。
在我写这篇文章的时候考虑一​​下，构建管道可以保持现状，它是基于生活在应用程序仓库中的Jenkinsfile构建的多分支管道作业，并基于对github的任何推送。
然后，我可以手动构建其他管道以进行部署-模板化，因此它们是通用的，并且仅将唯一变量传递给每个变量。

更新：

我想回来与此矛盾。在对设计进行了更多内部讨论之后，以及我作为Jenkins用户的成长，我回到了完成所有任务的单一管道。

不同之处在于使用较少的参数，并使用触发构建的分支/ PR控制流程。这样，尽管任务可能有所不同，但管道的输出仅基于其属性。

显然，这只需要一个管道就可以降低总体复杂性，尽管单个管道的条件检查可能会变得更加复杂以处理所有条件。

我还应该补充一点诸如流程图和图表之类的非代码设计工作帮助揭示了可能性-首先直接让代码隐藏了我的全貌。