GoCD, from ThoughtWorks in Chicago, is an application lifecycle management and development tool.
N/A
Kubernetes
Score 9.1 out of 10
N/A
Kubernetes is an open-source container cluster manager.
N/A
Spinnaker
Score 7.9 out of 10
N/A
Spinnaker is an open source continuous delivery platform with a range of cluster management and deployment management features, originally developed at Netflix.
N/A
Pricing
GoCD
Kubernetes
Spinnaker
Editions & Modules
No answers on this topic
No answers on this topic
No answers on this topic
Offerings
Pricing Offerings
GoCD
Kubernetes
Spinnaker
Free Trial
No
No
No
Free/Freemium Version
No
No
No
Premium Consulting/Integration Services
No
No
No
Entry-level Setup Fee
No setup fee
No setup fee
No setup fee
Additional Details
—
—
—
More Pricing Information
Community Pulse
GoCD
Kubernetes
Spinnaker
Considered Multiple Products
GoCD
No answer on this topic
Kubernetes
Verified User
Administrator
Chose Kubernetes
I didn't have too much experience or exposure to OpenShift but I do remember that in certain areas our organization found Kubernetes to be more useful and met our needs in comparison to OpenShift. Although I can't compare, I think it's easier to customize Kubernetes because of …
Even Jenkins being originally a Continuous Integration solution, I've used it as a Continuous Deployment solution as well, but Spinnaker brought to me a more focused approach allowing us to spend less time by creating and managing pipelines. While on Jenkins we need to install …
Previously, our team used Jenkins. However, since it's a shared deployment resource we don't have admin access. We tried GoCD as it's open source and we really like. We set up our deployment pipeline to run whenever codes are merged to master, run the unit test and revert back if it doesn't pass. Once it's deployed to the staging environment, we can simply do 1-click to deploy the appropriate version to production. We use this to deploy to an on-prem server and also AWS. Some deployment pipelines use custom Powershell script for.Net application, some others use Bash script to execute the docker push and cloud formation template to build elastic beanstalk.
K8s should be avoided - If your application works well without being converted into microservices-based architecture & fits correctly in a VM, needs less scaling, have a fixed traffic pattern then it is better to keep away from Kubernetes. Otherwise, the operational challenges & technical expertise will add a lot to the OPEX. Also, if you're the one who thinks that containers consume fewer resources as compared to VMs then this is not true. As soon as you convert your application to a microservice-based architecture, a lot of components will add up, shooting your resource consumption even higher than VMs so, please beware. Kubernetes is a good choice - When the application needs quick scaling, is already in microservice-based architecture, has no fixed traffic pattern, most of the employees already have desired skills.
Spinnaker suits well for applications which are stateless and can adapt to an immutable architecture of deployment. But for applications which are stateful and cannot afford to spin up new servers for every deployment doesn't go well with Spinnaker. It can handle only deployments which are VM based and cannot support deployments to serverless architecture like AWS Lambda etc.
Pipeline-as-Code works really well. All our pipelines are defined in yml files, which are checked into SCM.
The ability to link multiple pipelines together is really cool. Later pipelines can declare a dependency to pick up the build artifacts of earlier ones.
Agents definition is really great. We can define multiple different kinds of environments to best suit our diverse build systems.
Local development, Kubernetes does tend to be a bit complicated and unnecessary in environments where all development is done locally.
The need for add-ons, Helm is almost required when running Kubernetes. This brings a whole new tool to manage and learn before a developer can really start to use Kubernetes effectively.
Finicy configmap schemes. Kubernetes configmaps often have environment breaking hangups. The fail safes surrounding configmaps are sadly lacking.
The Kubernetes is going to be highly likely renewed as the technologies that will be placed on top of it are long term as of planning. There shouldn't be any last minute changes in the adoption and I do not anticipate sudden change of the core underlying technology. It is just that the slow process of technology adoption that makes it hard to switch to something else.
It is an eminently usable platform. However, its popularity is overshadowed by its complexity. To properly leverage the capabilities and possibilities of Kubernetes as a platform, you need to have excellent understanding of your use case, even better understanding of whether you even need Kubernetes, and if yes - be ready to invest in good engineering support for the platform itself
GoCD is easier to setup, but harder to customize at runtime. There's no way to trigger a pipeline with custom parameters.
Jenkins is more flexible at runtime. You can define multiple user-provided parameters so when user needs to trigger a build, there's a form for him/her to input the parameters.
Most of the required features for any orchestration tool or framework, which is provided by Kubernetes. After understanding all modules and features of the K8S, it is the best fit for us as compared with others out there.
• Pipeline Expressiveness • Self-Service/Override • Visibility of Client Teams • Operability of Client Teams - • High-Quality Integrations (AWS, IHP, Google) • Extensibility – (Ability to add code) • The maturity of Deployment Process • Speed/Ease of Onboarding
Settings.xml need to be backed up periodically. It contains all the settings for your pipelines! We accidentally deleted before and we have to restore and re-create several missing pipelines
More straight forward use of API and allows filtering e.g., pull all pipelines triggered after this date
