Spinnaker vs. Jenkins for Continuous Deployment

Continuous Deployment (CD) is a process that automates the deployment of code, sometimes referred to as an “artifact” into service.  While this could be deployed into a dev environment, it is most commonly deploying code into production, so as you may imagine, having a reliable process is vital.  Jenkins is a venerable, open-source CI/CD solution, while Spinnaker, precisely a CD solution, is a relative newcomer custom built by Netflix and open-sourced. 

Continuous Integration and Continuous Deployment (CI/CD) is a vital part of DevOps processes as it enables automation of application development (CI) and application deployment (CD).  While we’ve previously covered CI/CD in greater detail for this article, CI is the application development process that produces a deployable code artifact. CD is the process that takes that artifact and deploys it into a server environment.

While it has not been uncommon to cobble together CD processes with tools like Chef, Puppet, Ansible, or Salt, this approach often includes manual methods or the need to maintain scripts. Jenkins original functionality was a build server designed to provide CI functionality. A set of Pipeline plugins have extended Jenkins’ abilities to also function as a CD tool. Spinnaker is not a build tool but was specifically developed to support the CD process and is focused on working in cloud environments and at scale.  In this article, we will specifically consider the CD functionality that both tools provide.


There is little doubt that Jenkins is the most widely deployed automation server. Jenkins can run standalone on a server with a Java Runtime Environment (JRE) installed or run as a Docker container.  A host of Jenkins plugins extend its functionality beyond CI, and the Pipeline plugins, in particular, enable CD function. Some of Jenkins’ key CD features include:

  • CI and CD – Many users consider Jenkins as “just” a CI tool; however, it is an “extensible automation server,” so it readily provides CD functionality with Pipeline plugins. Releases since v2.0 have explicitly included CD targeted functionality.
  • Plugins – A significant way that Jenkins extends and integrates with function is through over 1500 plugins. Key integration categories are build and source code management, UX modifications, and administrative controls.
  • Distributed deployments – Speeds up CI and CD processes by distributing jobs across multiple servers.
  • Multiple use-cases – Plugins allow Jenkins to support a wide range of platform-specific use cases such as Java, Ruby, Python, Android, C/C++, PHP.

 We are focusing on Jenkins’ CD capabilities, the popular Blue Ocean UX plugin for Jenkins pipelines. Pipelines themselves are a suite of plugins that enable CD with Jenkins.  Pipelines are defined with text-based scripts; however, Blue Ocean allows users to visualize the CD pipeline process and results in real-time. 

An example of the UI from the Blue Ocean plugin documentation displaying the tests have failed or passed, and part of the test scripted that failed.


Netflix open sourced Spinnaker on GitHub in 2015.  Major cloud providers (Google, Amazon, Microsoft) quickly joined to support its development. Netflix and Google were the primary managers and drivers of development until creating a community governance system in 2018. Here is a selection of some key Spinnaker features:

  • CI Integrations – Not surprisingly, as a CD specific tool, CI integrations with Jenkins or TravisCI are available and can trigger the CD process.
  • Multi-Cloud – As a cloud-native tool, Spinnaker was designed to easily deploy across multiple cloud providers, including AWS (EC2), OpenStack, Kubernetes, Google (Compute Engine, Kubernetes Engine, and App Engine), Microsoft Azure, and DC/OS. 
  • Automated releases – This is a core function, and it is possible to run both integration and system tests in your deployment pipelines. A range of pipeline trigger events (e.g., via CRON, a git event, Jenkins, Travis CI, or another Spinnaker pipeline)
  • Deployment strategies With built-in deployment strategies define how an application rolls out. Built-in strategies include highlander and red/black (a Netflixism that the rest of the planet would call blue/green), rolling red/black, and canary. Of course, you can also define your custom strategy.
  • Integration monitoring – Monitoring service integrations (Prometheus, Datadog, Stackdriver) can trigger pipeline events, such as rollbacks, and provide the necessary canary analysis measurements.
  • Manual judgments – If you prefer continuous delivery over continuous deployment, you can use a manual judgment stage to require a human’s approval before deployment.
  • Chaos Monkey integration – An excellent value add that tests application resilience during instance failure. 

One of Spinnaker’s strengths is a robust set of deployment models.

Spinnaker vs. Jenkins

As Spinnaker is explicitly a CD tool, and Jenkins is the primary CI tool, it is not unusual to see both used together.  Spinnaker even has a native Jenkins API that makes the integration simple.  Still, the question we are delving into here is which application provides the more performant CD solution. Let’s looks at some of the differences in how Here are some of the key differences between them:

  • Spinnaker is a deployment tool, is not a build tool. This is Jenkins’ strength, which is why integrating the two (or integrating with another CI tool) is necessary to build a CI/CD pipeline with Spinnaker.
  • Jenkins is built for CI, and CD needs to be enabled through native plugins, scripting (Ansible, Puppets, etc.), or integration with another tool, like Spinnaker.
  • Jenkins was not designed for cloud deployments (Though JenkinsX is a cloud-native, Kubernetes-focused solution). Jenkins plugins or external scripts are required to enable cloud integrations. While the extensive plugin catalog does address many use cases, this does not guarantee your cloud-specific use case has a plugin available.
  • Spinnaker is a cloud-native, cloud-agnostic application with built-in functionality that allows on-demand infrastructure and application changes. It delivers highly-available, multi-account, multi-cloud artifact (code) deployment reliably and predictably. Spinnaker can create deployments, load balancers, automate version rollouts and rollbacks, resize clusters, etc. It also provides a web UI to both manage deployment processes and the creation of primary infrastructure resources.
  • Spinnaker provides the ability to manage deployments across cloud providers with a unified dashboard to handle process status and deployments across multiple cloud environments. 
  • Spinnaker provides a richer set of deployment models than Jenkins.
  • Jenkins is well known to be a temperamental application, in part due to its reliance on scripts for functionality. Spinnaker is built to provide a simple, reliable user experience.
  • The tradeoff for Spinnaker’s simplicity and ease of use is that it provides less fine-grained, resource-level access controls when compared to the functionality provided by Jenkins’ native configs and plugin extensions.


So, do you feel like there is a clear winner? I find that as more companies either start as cloud-native or move to the cloud, the simplicity and reliability, along with powerful integrated deployment models, give the edge to Spinnaker. This may be why it is not uncommon to see Jenkins used as the CI solution with Spinnaker providing the CD tooling.  Suppose you are already using Jenkins as your CI/CD solution. In that case, I am not sure that rebuilding your CD processes with Spinnaker would provide much of a benefit. If you move from a traditional or private cloud environment, switching to Spinnaker will likely speed up and simplify the process.