Compare Spinnaker with Jenkins 2.0 as a continuous delivery tool

Question

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?

Revanchism

Answer 1

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.

Livy

"the transition between Jenkins jobs and Spinnaker stages is pretty seamless". so Im using spinnaker to totally replace jenkins multibranch pipelines and pipeline stages OR I call the spinnaker API from inside a jenkins pipeline stage- right? – Lugworm

@Lugworm You'd still need Jenkins for build and test. I think the quote was meant that you can implement your top level deployment automation flow in either, and call the API of one from inside the another. It is probably not true that you can do anything in one of these tools, exclusively. – Botulin

Jenkins pipelines did not exist when we did the integration. Unless somebody has contributed this to Spinnaker, I imagine the support for them would be pretty suboptimal. – Livy

Answer 2

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.

Scramble

Thanx Neil very well explained :) – Pressroom

"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."- this is why im using them. So this isn't possible yet with spinnaker? – Lugworm

Answer 3

We use Maven to package entire code base along with configs , properties ( i.e. everything which is versioned in GitHub ) and create a RPM out of it. With this flow ending - we trigger Spinnaker pipelines in AWS or any other cloud to initiate the CD part.

Spinnaker is very unique with this given CD scope.

1. Code promotion : same RPM which we will promote up ensures that we are making our underlying code / env immutable.

2. We can control resizing of instances from the Spinnaker console itself

3. Roll back is just one click.

4. All modern deployment concepts like Blue-green / Red-Black , Canary , highlander etc. is OOB here.

5. Pipeline logs gives a very insightful view , both high level and low level

6. Multi region deployments ( DR strategic )

if anyone needs a help ( free help! ) on installing Spinnaker in RHEL , you can let me know.

But I must say we use Spinnaker only for cloud centric deployments.

Briticism

What do you use for CI? – Decoder

Jenkins suffice. Spinnaker understand artifacts in the RPM format , rpm-maven plugin can be used in POM to generate the RPM packages. Spinnaker can pick up those and build the pipeline. – Briticism