jenkins - 将 Spinnaker 与 Jenkins 2.0 作为持续交付工具进行比较

Question

众所周知，Jenkins 2.0 已经发布，并且正在从持续集成(CI)扩展到持续交付(CD)。所以我想问一下，Spinnaker相对于Jenkins 2.0有什么竞争优势？

Answer 1

我广泛致力于 Spinnaker 中的 Jenkins 集成以及 Netflix 的 Pipelines 功能。

Spinnaker 从来没有打算成为一个端到端的构建工具。 Jenkins 在管理 SCM、运行测试、构建包、拥有大量插件等方面会做得更好。

Spinnaker 试图做好的事情是采用您已发布的软件(debian 软件包、docker 镜像或可部署的 JAR)并通过高度可定制的可预测软件部署周期运行它。换句话说，Spinnaker 中的每个功能都是为了轻松进行高可用、多帐户、多云工件部署而构建的。

Spinnaker 管道采用以云为中心的 View 。我们的大多数管道阶段和 API 控制都涉及以可预测且用户友好的方式创建新服务器组和更改现有服务器组。当有疑问时，我们会针对这种情况进行优化。

我们对云部署的外观有更强烈的看法，并且在处理 CD 管道中的云部署任务时，我们通常会使用点击式 UI --- 查找集群 x 中的镜像、禁用该集群、调整大小一个服务器组，收缩这个集群，让这个集群承担流量，销毁这个旧集群等等。

两年多前我们开始编写 Spinnaker 时，Jenkins 管道功能尚不可用，因此我们构建了所需的功能。我们提出的 Jenkins 支持源 self 们帮助 Netflix 的其他团队在内部构建数千个部署管道的需求。由于 Netflix 严重依赖 Jenkins 进行构建和测试，因此 Jenkins 工作和 Spinnaker 阶段之间的过渡非常无缝。

Netflix 的一些团队不使用 Spinnaker 管道功能，而是在 Jenkins 作业中使用 Spinnaker API 作为部署到 AWS 的快捷方式。如果您使用 Jenkins 管道或类似的 CD 工具，Spinnaker 会使您的部署阶段变得非常灵活。

我们也有一些团队喜欢 Spinnaker 将 Jenkins 作业分解为围绕一个应用程序的原子的、可重用的任务。不部署到云的团队使用 Spinnaker，因为我们的管道比他们在 Jenkins 世界中找到的管道更能满足他们的需求。

Jenkins 管道非常整洁。我不认为 Spinnaker 会完全取代 Jenkins 及其所做的数百万件事。我们的目标是让“部署到云”步骤变得更简单、更具可扩展性。选择使用其中一种、一起使用还是根本不使用，都取决于您。