Compare Spinnaker with Jenkins 2.0 as a continuous delivery tool

As we know, Jenkins 2.0 has been released, and it is extending beyond just continuous integration (CI) to continuous delivery (CD). So I want to ask, what are the competitive advantages of Spinnaker compared to Jenkins 2.0?

I work extensively on the Jenkins integration in Spinnaker and in the Pipelines functionality at Netflix.

Spinnaker was never intended to be an end-to-end build tool. There are things that Jenkins will do better in terms of managing SCM, running tests, building packages, have gazillion plugins, etc, etc, etc.

The thing that Spinnaker tries to do well is to take a piece of software that you have published (either a debian package, a docker image, or a deployable JAR) and run it through a predictable software deployment cycle that is highly customizable. In other words, every feature in Spinnaker is built to make it easy to do highly-available, multi-account, multi-cloud artifact deployment.

Spinnaker pipelines take a cloud-centered view. Most of our pipeline stages and API controls are concerned with creating new server groups and changing existing server groups in a way that is predictable and user-friendly. When in doubt, this is the case we optimize for.

We have stronger opinions around how cloud deployment looks like and we will often have a point-and-click UI when dealing with cloud deployment tasks in our CD pipelines --- find the image in cluster x, disable this cluster, resize a server group, shrink this cluster, make this cluster take traffic, destroy this old cluster, etc.

Jenkins pipeline functionality was not available to us when we started writing Spinnaker 2+ years ago, so we built the functionality that we needed. The Jenkins support we came up with evolved from our needs helping other teams at Netflix build thousands of deployment pipelines internally. Since Netflix relies on Jenkins heavily for building and testing, the transition between Jenkins jobs and Spinnaker stages is pretty seamless.

There are teams at Netflix that do not use the Spinnaker pipeline functionality and instead use the Spinnaker API in their Jenkins jobs as a shortcut to deploy to AWS. If you're using Jenkins pipelines or similar CD tools, Spinnaker makes your deploy phase really flexible.

We also have teams that like the way Spinnaker breaks down Jenkins jobs into atomic, reusable tasks around one application. Teams that don't deploy to the cloud use Spinnaker because our pipelines fit their needs better than what they can find the Jenkins world.

Jenkins pipelines are pretty neat. I don't think Spinnaker will ever fully replace Jenkins and the million things it does. Our goal is to just make the 'deploy to cloud' step simpler and more extensible. The choice to use one over the other, together, or not at all, is up to you.

There are a few reasons you might choose Spinnaker over Jenkins (2.0) Pipeline as a CD tool:

1. Spinnaker includes a web UI that can actually provision resources, and do so in multiple cloud environments. So to create basic resources like VM's, load balancers, clusters, etc. you are able to do this from the same UI as your delivery tool.
2. If your architecture is similar to Netflix's, Netflix uses this as their entire cloud management platform, so little to no need for sprawled tools to support your delivery and infrastructure management.

On the other hand, there are many reasons to choose Jenkins Pipeline over Spinnaker

1. Spinnaker still requires a build tool, so you may need to maintain Jenkins anyways. So if Jenkins Pipeline becomes your CD tool, it can natively perform your executor-specific tasks already.
2. Spinnaker has no fine-grained access controls (and only recently added authentication of any kind), whereas Jenkins has many plugins and native configurations within Pipeline to offer resource-level access control.
3. Everything is driven by a single groovy script, so it is true configuration-as-code. It allows for simple flow/logic/control that is not possible (or at least easy) in other CD tools.
4. Multi-branch pipeline support, easily create/remove/change branches
5. Extensive plug-in support for Jenkins already. For example, we are using the AWS ECS Plugin to allow dynamic docker nodes for our pipelines.
6. Easily share/collaborate on code towards pipelines. You will certainly have reusable functions you want to utilize across multiple pipelines, Jenkins makes this easy with tools such as Remote Loader Plugin
7. Large community support

We ultimately chose Jenkins 2.0 Pipeline as our CD tool over Spinnaker and several others.