Build Pipeline Plugin如何与Jenkins 2 Pipeline Plugin相关联？

Question

目前，我使用Build流水线插件通过不同的环境来协调我的代码交付：

1. 构建代码并执行单元测试
2. 手动部署到开发环境
3. 自动执行测试在开发环境上
4. 手动发布软件并将版本号发布到发布版本。
5. 手动通过从库下载制造品的基础上，通过版本的发布版本把部署到集成测试环境。
6. 手动部署到...

随着詹金斯2.0自带的流水线插件。但是这两个插件如何相互关联？

我应该迁移到最新的插件吗？我似乎从Jenkins 2 Pipeline插件中错过的东西：

• 手动触发一个阶段。我可以等待输入，但似乎没有那么优雅
• 重新启动一个阶段以重新触发部署。这似乎不可能。
• 对用于触发舞台的参数的可见性，例如已部署软件的版本号。

我在这里是否缺少重点？他们两个是否应该合并？或者你如何接近这样的管道？

Answer 1

随着詹金斯2管道的当前状态，您正确地陈述了您列出的所有“缺失功能”。

Jenkins 2管道插件的一个优点是，与使用Build Pipeline Plugin将一系列作业链接在一起，您的整个管道是1'工作'，这使得用户管理更容易IMO。

Jenkins 2管道的另一个优势是'配置为代码'，因此您可以像管理版本控制中的任何其他文件一样跟踪管道更改。

Jenkins 2管道是非常新的'热点'，并且有很多插件实现日复一日的兼容性。

一旦新的用户界面变为生产准备就绪，我会想象旧的生成管道插件将开始被弃用。

另外你应该知道，据我所知，Jenkins或CloudBees团队并不维护Build Pipeline插件，而Jenkins 2的管道是。

我会建议现在进行移植吗？不，我个人仍然认为Jenkins 2管道不够成熟，无法部署到组织中进行生产。在等待Jenkins 2 Pipeline生态系统成熟时，我会坚持使用你现在知道的。

我的理论，我在博客中发布了几个星期前（read more here if you want，但我已经提取出的“弱点”在这里等你）：

• 仍有许多插件，我和很多的其他人将认为'他们的CI管道的核心'缺少对管道的全部或部分支持。
• 许多插件管道中缺少'per-project-configuration'。例如松弛 - 当前实现'假定'所有的Jenkins 2 Pipeline项目都应该传递到相同的Slack频道/团队 - 而您可能想要配置多个Slack团队。还有其他多个插件。
• 目前詹金斯2管道的文档非常有限，虽然这有所改进。