Build Pipeline Plugin如何与Jenkins 2 Pipeline插件相关？

Question

目前，我使用Build Pipeline Plugin来编排通过不同环境传递我的代码：

1. 构建代码并执行单元测试
2. 手动部署到开发环境
3. 自动执行开发环境测试
4. 手动释放软件并将版本号添加到已发布的版本中。
5. 根据发布版本的版本，从存储库下载artefact，手动部署到集成测试环境。
6. 手动部署到...

使用Jenkins 2.0来自Pipeline插件。但是这两个插件如何相互关联？

我应该迁移到最新的插件吗？我似乎错过了Jenkins 2 Pipeline插件中的内容：

• 手动触发舞台。我可以等待输入，但它看起来并不那么优雅
• 重新启动舞台以重新触发部署。这似乎不太可能。
• 对用于触发舞台的参数的可见性，例如已部署的软件的版本号。

我在这里错过了这一点吗？这两个人应该合并吗？或者你是如何接近这样的管道的呢？

Answer 1

使用Jenkins 2管道的当前状态，您可以正确陈述您列出的所有“缺失功能”。

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

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

Jenkins 2管道非常具有新的“热度”，并且有许多插件日复一日地实现兼容性。

一旦新UI准备好生产，我想象旧的构建管道插件将开始被弃用。

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

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

几周前我在一篇博文中给出了我的推理（read more here if you want，但我已经为你找出了'弱点'）：

• 我和其他许多人认为仍然有很多插件“他们的CI管道的核心”缺少对管道的全部或部分支持。
• 许多插件的管道中缺少“每个项目配置”。例如Slack - 当前实现'假设'所有Jenkins 2 Pipeline项目都应该传递给同一个Slack通道/团队 - 而您可能希望配置多个Slack团队。还有其他多个这样的插件。
• 目前，Jenkins 2 Pipelines的文档非常有限，尽管情况正在改善。