本文由 简悦SimpRead 转码，原文地址 gsaslis.github.io
因为与任何 "代码 "一样，我们希望 "作为代码的Jenkins管道 "有一个体面的开发环境......。
因为和任何 "代码 "一样，我们希望 "作为代码的Jenkins管道 "也有一个体面的开发环境，对吗？
好吧...
tl;dr 这不是今天的梦想景观...
在下面的章节中，我将保留一些笔记（主要是给自己的，但希望能帮助其他一些正在编写Jenkins管道的人），作为启动和运行的参考。这是一个WIP--也欢迎反馈!
你看，我所在的团队现在正在努力扩展它已经到位的自动化，围绕着我们在Red Hat这里所说的 "产品化 "过程。这是一个处理从 "上游 "开源项目发布 "产品 "版本的过程。
我们的开源项目在3scale GitHub org --3scale是红帽主导的API管理的完全开源的解决方案（认为Auth*、速率限制、货币化、反向代理等是你部署在API前面的一个额外的组件，所以你不必在自己的代码库中实现这些逻辑。我们已经做到了，它是开放源码软件。去使用它吧! ）。
回到主题......现有的自动化是基于Jenkins的（我们需要灵活性），所以尽管多年来维护--和升级--一个自我托管的Jenkins及其插件的痛苦并没有让我成为其最大的粉丝，但在这个问题上没有什么选择（由于一些非常合理的原因）。
无论如何，让我们开始研究我们的Jenkins管道开发环境的各个要点，首先是......我们的管道是用什么语言编写的
Groovy DSL vs. Job DSL vs. Pipeline DSL (Dynamic Pipeline vs. Scripted Pipeline) vs. Dynamic DSL vs. Groovy
...真是一团糟...
-
这里有一个很好的StackOverflow答案解释Job DSL和Pipeline DSL之间的区别，因为这是主要的分离（tl;dr Job DSL是用于创建Jenkins作业本身，Pipeline DSL是其实现的写法。如果你现在在想，"所以我需要这两个？"，不幸的是，答案是 "是的"，如果你在想 "那不是很好，是吗？"答案是--再次--"不幸的，是的")
-
GroovyDSL（或GDSL）是一个脚本框架，用于IntelliJ支持外部DSL（如Jenkins Job DSL）。所以你基本上从Jenkins导出一个gdsl文件，把它安装在IntelliJ中，它现在知道如何为Job DSL做一些语法高亮和代码完成。
-
考虑到Job DSL是一个基于Groovy的DSL，是的，你也可以在你的Job DSL中写Groovy。这很有帮助，但只是在一定程度上。记住，Job DSL增加了很多额外的东西，所以你可能希望使用的任何Groovy工具不一定能满足你在这里的所有需求。
-
动态管道vs.脚本管道：首先，记住我们是在 "管道DSL "的BoundedContext中。我们谈论的是管道的实现，而不是作业。要了解这些区别，这是正确的地方。Tl;dr Declarative的限制更多，但有低的学习曲线，使其成为较简单管道的理想选择。Scripted提供了非常少的限制，但有更陡峭的学习曲线（Groovy），使其成为权力使用者和有更复杂要求的人的理想选择。为了使事情更加复杂（和灵活），你甚至可以在Declarative管道内使用
script块，在那里你可以使用Groovy。 -
上面的 Dynamic和Scripted 不要与Dynamic DSL混淆，后者是Job DSL插件的一部分。那是Job DSL的一部分，增加了对插件的支持。混乱了吗？
有效的语法和IDE支持
我已经习惯了指尖上的代码补全和自动语法高亮/修正，我发现必须专注于获得正确的语法是非常分散精力和低效的。我的意思是，我应该专注于让代码做我想做的事。语法是一个实现细节，而IDE很好地将其抽象化了......
所以我通常使用IntelliJ。我尝试的第一件事是为Jenkins中使用的各种DSL找到一个插件。
- 有一个Jenkinsfile插件，但它不是那么好很遗憾...
- 然后我去看了关于IDE支持的官方文档。 tl;dr 动态作业DSL不被支持，但是，是的，你可以得到一些语法高亮/自动完成的工作（通过我们上面提到的GDSL）。
Pipeline DSL的问题是，可用的结构取决于正在使用的Jenkins实例中安装的插件。
下面是我遇到的一个最完整的GDSL输出的例子。
或者你可以直接到https:///job//pipeline-syntax/gdsl，下载你的GDSL，如下图所示
确切地说，因为DSL中可用的语法取决于你的Jenkins实例中安装的插件，如果一些IDE能根据实际要运行的Jenkins服务器来检查我的文件的语法，那就更理想了。
进入VSCode...
好吧，Visual Studio Code带有一个扩展，正是这样做的! Jenkins流水线连接器。
足够的理由让我们远离IntelliJ! (只针对这个项目......目前......)
- Jenkins Job DSL Playground: 一个heroku网络应用程序，允许你测试你的dsl，并验证为你的作业配置生成的XML是否正确。
- 官方Job DSL的API参考文档
- jenkins.io/blog/2017/0…
测试Jenkins管线
现实情况是，今天开发Jenkins管道仍然依赖于大量的手动测试，以确保一切工作正常。 : (
测试CI服务器本身就是一个大话题，可能值得自己写一篇（几篇）博文。现在我只想把这些想法留给你。
测试以下顺序有多容易。
- 启动一个Jenkins工作节点（可以是AWS EC2实例/另一个云虚拟机/一个容器，等等）。
- 运行虚拟机的初始脚本（安装一些基本工具--如git）。
- 运行Jenkins管道，验证步骤是否按计划执行。
也就是说......如何验证为运行其他验证测试而设置的环境本身是正确设置的？
你看，在你开发管道本身的时候--也就是说，当你还在开发阶段的时候--出现的许多测试失败都是由于环境本身的一些错误配置。
测试失败通常不是来自于你团队中的一个开发人员的测试失败。这发生在后来，一旦管道脱离开发，进入 "生产"--即被开发团队使用时。
传统上，跨越SUT障碍的测试，像上面的例子一样，通常发生在测试双击。
我将留待以后的文章来阐述这个问题--但只是把这个留在这里，以便你知道它的存在。
另外，一些链接，供进一步阅读。
创建Jenkins管线的可视化向导
实际上，Jenkins本身有一个非常漂亮的编辑器（一旦你安装了Blue Ocean插件）。
问题是这个编辑器非常......隐蔽......我是偶然发现的!
这里是如何访问它! (考虑到蓝海仍然处于相当活跃的开发阶段，它们可能会发生变化，我将链接到文档，而不是在这里写说明）。
它对于开始工作和建立一个基本的管道是很好的。
你很快就会发现并不是每个字段都被完全支持，但是--嘿，至少它让你开始了！;)
有用吗？
我知道这些信息不是特别有条理，但它更多地是作为一个保存链接/思维导图的地方，而不是一个适当的帖子。如果有足够多的人觉得这很有趣，我可以投入更多的精力来组织/扩展这里的部分，甚至可以创建一系列的帖子来分别涵盖各个要点。
哦，还有......谢谢你读到这里! 没想到你能做到... :P :D
