Both Spinnaker and Boost aim to provide a straightforward path towards continuous delivery; however they start from different perspectives and then take very different approaches.
- Spinnaker is an enterprise deployment framework that allows engineers to build continuous delivery solutions
- Boost provides an adaptable prebuilt continuous delivery solution that utilises the deployment features from OpenShift
Boost builds on the capabilities of OpenShift, providing an opinionated approach and, crucially, an adaptive delivery process. We know that every organisation is different whilst sharing common problems such as provisioning environments, linking these via pipelines and guarding each promotion with quality gates according to the purpose of each environment.
Boost also provides a real-time view of product delivery, showing features rather than code artefacts (we also have a microservices view) which are tagged in source control, linked to cards in JIRA / Trello etc. and then identified within OpenShift pods. This is not something Spinnaker is concerned within, which instead focusses on deployments into sometimes complex environments. Boost is also entirely test-driven – although you of course have complete flexibility as to the tools you use and how they are executed.
The diagram on the right illustrates the different spaces the two solutions address. If you’re only using Kubernetes, then you may well need the additional capabilities of Spinnaker. If you are an OpenShift customer, then you already have many of the capabilities of Spinnaker out-of-the-box: you could still add Spinnaker to your OpenShift estate, but there’s limited value in doing so.
Boost takes OpenShift and addresses all the points of friction we find in a typical delivery process and which, by extension, have historically made Continuous Delivery hard. By making it much, much easier to consume OpenShift (e.g. by automating and versioning the approach to pipelines, environments and quality gates), we aim not only to accelerate OpenShift adoption but to ensure sustained high velocity for your teams. This includes:
- A delivery approach focussed on of a product (or set of products) rather than a set of tools and concepts for deployments
- Leveraging the built-in features of OpenShift such as the standard OpenShift objects creating deployments and resources (e.g. deployment configs, templates etc), but using these in a quick to define and version
- Out-of-the-box pipeline automation so effort is directed on implementing quality gates between environments
- Boost supports a green / blue deployment strategy that must be utilised only in a production environment.
- Boost enables transparency across the process: users can see what is deployed where so that they can make informed decisions and share a common view with the rest of the team