The previous sections of this report have covered built-in or planned functionality for Spinnaker. However, Spinnaker enforces a particular paved path that doesn’t represent every use case.
There are four main ways to customize Spinnaker for your organization: API usage, building UI integrations, writing custom stages, and bringing your own internal logic. This chapter will dive into those scenarios with an example of each. At the end of this chapter, you should have a good understanding about how to customize Spinnaker beyond the out-of-the-box deployment experience provided.
The first way to customize Spinnaker is by hitting the API directly. Teams at Netflix use the Spinnaker API for a variety of reasons.
Some teams want to create security groups and load balancers programmatically as part of spinning up full deployment stacks for services like Cassandra, which isn’t a supported flow via the UI. Teams use scripts to create this infrastructure.
Another popular API use case is managing workloads that don’t fit Spinnaker’s deployment paradigm. Teams may have existing orchestrations but use Spinnaker to do the actual creation and destroying of infrastructure. Scripts are used to orchestrate deployment of multiple applications or services that depend on each other and have a more complex deployment workflow.
A third group of teams use the Spinnaker API to build their own specialized platform UI. This helps them surface only the information ...