本文由 简悦SimpRead 转码，原文地址 www.theserverside.com
CI/CD的声明式管道与脚本式管道的争论是片面的。以下是这些Jenkin......
脚本式管道曾经是CI/CD的标准，但它们几乎已经绝迹，并被声明式管道所取代。看看它们是如何比较的，什么时候各自的效果最好。
Jenkins为管道提供了两种不同的语法。当DevOps工程师编写Jenkins管道时，他们可以选择声明式和脚本式。两者之间的区别既微妙又重要。
让我们探讨一下声明式管道与脚本式管道在Jenkins开发中的区别，以及开发人员在选择语法之前需要了解的内容。
Groovy脚本式管道
当Jenkins管道刚被引入时，脚本化管道是唯一可用的选择。软件开发人员热情地接受了脚本管道，有两个主要原因。
- 它提供了一种特定领域的语言，简化了Jenkins开发者要执行的许多任务。
- 同时，它允许开发者随时将Groovy代码注入他们的管道中。
Groovy是一种基于JVM的编程语言，这意味着使用Groovy的脚本化Jenkins管道可以访问JDK打包的大量API。脚本化管道的开发者拥有巨大的权力。
事实上，权力太大了。
脚本化管道的缺点
开发社区发现，具有很强的Java和Groovy技能，但对Jenkins没有什么经验的管道建设者，往往会编写复杂的Groovy代码来增加Jenkins DSL已经提供的功能。
Jenkins管道应该是一个简单、易读、易管理的组件。脚本化管道中过多的代码违反了CI/CD基本原则之一。
因此，Jenkins在引入声明式管道时纠正了这种趋势。
声明式管道与脚本式管道的对比
与脚本式管道相比，声明式Jenkins管道不允许开发者注入代码。Groovy脚本或声明式管道中的Java API引用将导致编译失败。
虽然这种限制在表面上听起来很有局限性，但其实不然。
Jenkins DSL提供了各种设施来引入简单的条件逻辑。声明式流水线支持条件性语句的使用，允许访问环境变量，并提供设施来增加日志和错误处理。其代价是，声明式管道不允许深度集成到Groovy和Java API。
但是，那些只有在开发人员访问Groovy和Java编程语言所提供的丰富的API集时才能解决的困难的角落案例怎么办？不能在管道上编写Groovy代码不会限制其解决企业中不可避免的困难和挑战的CI/CD问题的能力吗？
简短的回答是不，不会。
简单地说，永远不要把复杂的代码放到流水线上，不管它看起来是否可行。Jenkins提供了几种方法，使复杂的逻辑可用于脚本式和声明式管道。隔离复杂代码的一种方法是将逻辑编码到Jenkins插件中。它提供了在多个Jenkins安装中可重复使用的额外好处。Jenkins还支持共享库，它允许开发人员在标准IDE中编写和维护复杂的代码，然后可以通过构建管道中的导入来引用。
不让复杂的代码进入Jenkins管道一直是一个最佳实践。声明式流水线简单地执行了这一点。
相同，但不同
脚本式管道与声明式管道的不同之处仅在于其程序化方法。一个使用声明式编程模型，而另一个使用命令式编程模型。
但它们都在同一个Jenkins管道子系统上运行。在声明式管道与脚本式管道的争论中，在运行时性能、可扩展性和问题可解决性的角度没有任何区别。它们只在用于实现最终目标的语法方法上有区别。
管线语法的差异
声明式管道总是以管道这个词开始。另一方面，脚本式管道总是以单词node开始。声明式管道将各阶段分解为独立的阶段，可以包含多个步骤。脚本式管道在阶段元素中使用Groovy代码和对Jenkins管道DSL的引用，不需要步骤。
这些是关键的区别，可以让开发者快速区分脚本式管道和声明式管道。
声明式管道与脚本式管道在语法上的区别
现在，对于一个新项目来说，在声明式管道与脚本式管道之间如何选择？这个问题的答案无疑是声明式管道。
开发行业在很大程度上已经转向CI/CD管道的声明式编程模式。GitHub Actions和GitLab CI都只支持YAML pipelines，这与声明式Jenkins管道非常相似。
此外，声明式管道更容易维护，而且它们的学习曲线往往更低。在构建新的CI/CD工作流时，声明式语法是最好的方法。
