It is not uncommon for Jenkins and Spinnaker to be mentioned in the same conversation.
Spinnaker and the new Jenkins X both target DevOps and continuous delivery/deployment with notable differences in their target use cases. This post will help you choose the best fit for your organization by identifying the use cases for each. This starts with a discussion on the process behind deployment pipelines.
Identifying Your Deployment Pipeline Needs
High-performing Engineering teams are deploying more frequently than ever before. This is due to a shift toward DevOps principles and practices, along with a growing niche of high-quality deployment tools. These tools position themselves as continuous deployment tools or deployment pipeline management software. Generally speaking, the software deployment follows this process:
Commit source control
Run a series of tests
Produce an artifact (e.g., a Docker image, virtual machine image, deb/rpm package, etc.)
Deploy the artifact to UAT/staging
Promote the build to production
It is possible to assess tools like Spinnaker, Jenkins X, Heroku Flow, and even GitLab’s Auto Devops according to how much (or how little) they control each step in the process. Tools vary greatly in how they support the last two steps.
Kubernetes has been winning more hearts and minds and has become the standard deployment target for containerized applications. Tools like Jenkins X and GitLab Auto Devops leverage this to target Kubernetes as a deployment platform. This implies that the application is containerized, where the tool may build the Docker image or offload that responsibility to end users.
Other tools like Spinnaker in addition to providing native Kubernetes deployment support created and supported by Google Team, also support multi-cloud deployment strategies using providers such as Amazon AWS, Microsoft Azure, Google Cloud Platform, Oracle Cloud and other platforms like Openshift, Pivotal Cloud Foundry, Openstack, DCOS. Deployment strategies are another key differentiator. Deployment strategies like canary, red/black (also known as blue/green), and rolling releases provide more control and stability to teams that are serious about continuous deployment. Tools that only target a specific platform are limited to whichever—if any—deployment strategies are supported and do not provide a single pane of glass that most Enterprises that are containerizing workloads need. Spinnaker provides a "golden path, with guardrails" level of standardization across multiple deployent targets and clouds, and visibility into all your cloud infrastructure.
This is when you must identify your needs. Do you need a single pane of glass? Do you need multi-cloud deployments? Do you need sofisticated deployment strategies? Do you want to combine your build and deployment tools? Jenkins X and Spinnaker answer these questions differently. Jenkins X is a deployment manager that also doubles as build server (given that it is still Jenkins under the covers). Spinnaker is a multi-cloud deployment manager with support for multiple deployment strategies, and is not a build server.
Jenkins X: Containerized Deployment Pipelines
Jenkins X was announced in March of 2018. The primary focuses of this release is to extend Jenkins Core to enable automation and management of containerized applications deployed to Kubernetes. Jenkins X manages deployment via source control. Each pull request is built and deployed to its own, isolated preview environment. Merges to master are automatically promoted to staging. Jenkins X keeps environment configuration in source control. Deployments to master are done via pull request to the production configuration repository. There is no GUI at this point in time.
Jenkins X is a running system itself, so you will have to set it up and run it somewhere. The JMX CLI can install Jenkins X on an existing Kubernetes cluster. It is important to note that Jenkins X does not manage Kubernetes, so teams will have to manage their own clusters or opt for a managed solution like Google Kubernetes Engine, Azure Kubernetes Service, or Amazon Container Service for Kubernetes.
Spinnaker: Cloud-Agnostic Deployment Manager
Spinnaker is a mature and battle-tested software delivery platform by Netflix and Google used n production by some of the largest brands in the world that supports multiple artifact types, cloud providers, and deployment strategies. Spinnaker is not a continuous integration tool. Rather, it is designed to coordinate deployments using robust deployment strategies. The following image from Google Team illustrates how Spinnaker fits into deployment pipelines.
The deployment pipeline is usually triggered by the continuous integration system when a new deployable artifact (e.g., a machine image, JAR file, or Docker image) is ready. Spinnaker then deploys that immutable image to AWS, Google Cloud, or Kubernetes. Spinnaker supports the canary, red/black (blue/green), and custom deployment strategies. Promotion between stages is automatic or manual. A "single pane of glass" GUI presents the state of all pipelines so any team member can identify what is running where and the current status.
Spinnaker does not manage 100% of the infrastructure, but teams can use a native Spinnaker Terraform integration to create VPCs, subnets, etc. and configure pipeline steps accordingly. Spinnaker will manage the rest.
Spinnaker is also a running system, so it is up to you to set it up and manage it. Or, you can choose Armory's enterprise-grade managed solution.
Selecting for Best Fit
Spinnaker and Jenkins X have different value propositions.
Jenkins X is Jenkins at the core, integrated with a complex pairing of open-source Kubernetes tools to offer a prescriptive CI/CD pipeline with best practices built-in, such as using GitOps to manage environments.
Spinnaker is purpose built open-source software delivery platform optimized for enterprise-grade deployments across varying cloud providers, inlcluding native support for Kubernetes, which is created and actively maintained by Google. This information, paired with the size of the community alone be may enough for you to decide, but let’s get a bit deeper.
Spinnaker can easily support smaller as well as enterprise teams with support for multiple artifact types and deployment targets. Organizations might prefer Spinnaker as the deployment system. Teams may opt to produce binary packages, Docker images, or JARs and deploy to the desired infrastructure. There are no build system requirements either, but Spinnaker can be triggered via API calls or even Jenkins jobs (which is likely already being used by large organizations). These bundled deployment strategies ensure reliable deployments across low- and internet-scale systems. The unified GUI is invaluable since it provides all relevant data to business, development, and operations personnel.
Jenkins X is a good fit for small teams that are comfortable with Jenkins core. Choosing Jenkins X also means betting on a young project with a very little adoption, uncertain future and comminity backing. There will certainly be bugs, missing features, and other rough edges that you will need to resolve on your own.
The choice is clear for enterprise and larger organizations. Spinnaker is mature and battle-tested. Jenkins X is very young with a few committers. Spinnaker offers canary deployments, multiple artifact types, immutable infrastructure, and multiple deployment targets—all of which scale to small and large teams. It also offers the "single pane of glass" GUI that is useful to business and technical stakeholders. Given that Spinnaker makes no assumptions about the build systems, organizations are free to integrate Spinnaker with any existing build systems.
Larger and enterprise organizations need not even consider Jenkins X. Jenkins X makes more sense as pilot project in a smaller team or division. Really, it is hard to go wrong with Spinnaker.