Here's some bad news: there is no one-size-fits-all continuous delivery platform.
While Spinnaker is notably pluggable and extensible, the platform's open-source nature means teams will always have use cases that won't be natively supported.
The good news is that Spinnaker is highly flexible and can be customized beyond the out-of-the-box deployment experience. Here are four scenarios (with examples) to give you a better idea of how you can customize Spinnaker for your organization.
1. API usage
The first way is having a go at the API. Here are a few examples from Spinnaker’s free eBook on Continuous Delivery which showcase how teams at Netflix use the Spinnaker API.
- Create security groups and load balancers, using scripts to create the infrastructure.
- Managing workloads that don't fit Spinnaker's deployment paradigm with scripts to orchestrate deployment of multiple apps or services that have a complex deployment workflow.
- Build a specialized platform user interface to show only the information their engineers need.
2. Build UI integrations
Customizing the UI to surface only what your team needs to see will help reduce the cognitive load on your engineers.
At Netflix, they've done their fair share of fiddling with the UI and came up with a useful shortcut to copy the ssh command to each running instance. The copy ssh command button then shows up next to the instance ID.
3. Write custom stages
The great thing about Spinnaker is you can use it to call out custom business processes via the Webhook or Run Job stages. But for more complex integrations you can write custom stages which allow you to build your own UI and show specific data.
The ebook mentions how Netflix has created multiple custom stages that integrate with internal tools. Like their own stage to do squeeze testing, for example.
4. Bring your own internal logic
You can package your own JARs inside specific Spinnaker services to fine-tune the platform's behavior to match the needs of your organization.
Let's stick with Netflix for this last example. Since they use multiple cloud providers, they require custom logic to support them in the frontend and backend services of Spinnaker (Deck, Clouddriver, Orca, and Gate). They have also extended Clouddriver in particular to "support early access to AWS features."
This all goes to show that Spinnaker can be extended in more ways than one, which means you have the flexibility to create a system that works for your deployment.
Recommendations for first-time "extenders"
At the 2017 Spinnaker Summit, a panel of Engineers hailing from Google, Netflix, Armory, and Oracle were kind enough to offer some empirical advice for those breaking into the art of extending Spinnaker.
- Join the Spinnaker Slack channel.
- Take the time to understand the code, how it works, and what the different parts are before you think about extension.
- Figure out your "deploy story" before you start with test runs. This enables a faster iteration cycle rather than panicking over how you're going to deploy into your test environment at the very end.
- Go back in the Git history and review how other cloud providers have contributed to Spinnaker so you can follow their implementation patterns.
Learn more about Spinnaker for your organization
We're just a few weeks away from the long-awaited Spinnaker Summit, but you're still in time to get a full-access ticket and spend two jam-packed days of learning from the experts and lounging with industry leaders.
From hands-on bootcamps introducing Spinnaker (featuring Kubernetes as the cloud provider) to open office hours for anyone playing around with the Spinnaker UI, if you're in the business of delivering software it would almost be a sin to miss this Summit. Get your ticket here and make sure to follow us on Twitter for the latest updates on who's going and what's happening.