Evaluating GoCD vs Spinnaker
Jun 16, 2017 by Armory
“So how do GoCD and Spinnaker compare?” is a question we’re sometimes asked by companies evaluating deployment tools.
While it’s a comparison of apples to oranges (a more apt comparison would probably be between GoCD vs Jenkins), we felt that it was important enough to address what each tool provides. To be unbiased in our opinion of GoCD, the following information pertaining to GoCD has been collected and synthesized from Arthur Burkart, a DevOps engineer at SimpliSafe that currently uses the non-enterprise version of GoCD but has had some experience with Spinnaker.
Arthur and SimpliSafe’s experience with GoCD (all of the quotes below can be attributed to Arthur):
- GoCD is a great CI tool for SimpliSafe’s needs, but Arthur says that “the CD in GoCD is no more CD than is the case for Jenkins. Really, GoCD should’ve probably been called GoCI. It offers very little in the realm of deployments or delivery. Maybe it offers more if you’re a Java shop; that’s an angle I have yet to explore. GoCD uses build agents the same way Jenkins does.“
- The reason SimpliSafe uses GoCD at all is because: “At the time of [GoCD’s] open-source inception, there were no other options on the CI/CD market that offered as robust a pipeline implementation as GoCD. Pipelines were finally a first-class citizen, which meant you could easily see all the dependencies that went into building your final, deployable artifacts.”
- Times have changed, and GoCD is no longer the only deployment tool that treats pipelines as a first-class citizen. Spinnaker goes a step further than this and treats all pipelines, stages, and builds as first-class citizens.
- “Our GoCD build agents aren’t on-demand, which is a feature Jenkins has offered for years. Our build agents are always running and we’re always paying for them. I hear that in later versions of GoCD, this may not be true (I think we’re one full major version behind at this point), but it’s hard to explore because the changelogs GoCD provides are vague in some areas, which makes it difficult for us to upgrade confidently.“
- As a side note from Armory: Due to this build agent that is constantly listening, it sounds like the infrastructure built with GoCD is inherently mutable. We believe in the power of immutable infrastructure, which allows for companies to deploy confidently and utilize important deployment strategies such as canaries, blue/green deployments, and rollbacks. The future of deployments hinges on the confidence that immutable infrastructure brings.
- “GoCD is far too inflexible. I get that the original implementers had some strong ideas about how the world should work, but based on what I’ve read, the ideas haven’t translated so well to other companies.”
- Note from Armory: It’s already known that Jenkins has the most plugins – we estimate GoCD to have less than 1% of Jenkins’ plugins. While we can’t compare Spinnaker to GoCD directly, we CAN say that Spinnaker is built out of the box to talk directly to Jenkins, and therefore offers the developer team the full suite of Jenkins plugins.
- “I think purely from an investment perspective (time and effort), we’re definitely vendor-locked to GoCD. It has a steep learning curve, its UI is pretty opaque (apparently improved in the latest version), it has a lot of awkward demands that influence the structure of our pipeline code in ways that aren’t always intuitive, and it doesn’t translate to a lot of other CI/CD tools. Our fluency in the product is hard-won.”
- Arthur’s two reasons for disliking GoCD’s UI:
- I have to perform most user management in raw XML because their UI doesn’t allow everything I’d expect
- The “pipeline edit workflow” is completely divorced from the “pipeline view workflow”
- Arthur’s two reasons for disliking GoCD’s UI:
- GoCD is a good tool for creating simple, automated workflows; not necessarily about deployments but focusing on the workflow. It is a strong continuous integration tool, but has some shortfalls when it comes to continuous deployments.
- GoCD is not cost efficient as Arthur points out that they are always paying for running build agents – and that these agents make your infrastructure vulnerable to mutability.
- GoCD has a steep learning curve with a confusing UI and makes awkward, unintuitive demands on the pipeline structure.
Less “obvious” points:
- Armory is a strong proponent of adopting “shipping small diffs” as an organizational best practice mindset. The right mindset requires the right tools, and while GoCD is great for CI, it does not do the CD part correctly enough to complement this best practice mindset.
- GoCD is written in Java and Ruby, which may matter if your infrastructure needs to be overhauled for integration.
- Documentation on how to create your own pipelines is not great; and due to the significantly fewer number of plugins available on GoCD this may eat up developer time when they have to code it from scratch.
- GoCD renders every single pipeline on page load, which becomes a resource clog when you have thousands of them.
- GoCD does not support autoscaling agents as well as Jenkins does with SWARM out of the box.
As with many companies in their journey to Stage 5 of software evolution, starting with CI before moving to CD helps get the organization comfortable with the more forward-thinking concepts in Stages 4 & 5 like continuous delivery, continuous deployment, full service ownership, and automated canaries. Arthur’s organization has not yet adopted Spinnaker, as GoCD is providing the CI functionality his organization is currently prioritizing. Armory is happy to provide a Proof of Concept of Spinnaker’s functions for companies that are looking to move further than simple CI and into the CD territory of automating deployments.