Spinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes with high velocity and confidence. It is being chosen by a growing number of enterprises as the open source continuous deployment platform used to modernize their application deployments. Most of these enterprises deploy applications to multiple clouds. One of Spinnaker’s features is its ability to allow users to deploy applications to different clouds using best practices and proven deployment strategies.

Until now customers who had standardized on Spinnaker had to use custom/different tooling to deploy their applications to Azure.

With this blog post and the recent release of Spinnaker (1.13), we are excited to announce that Microsoft has worked with the core Spinnaker team to ensure Azure deployments are integrated into Spinnaker!

These integrations will strengthen our existing open source CI/CD pipeline toolchain and allow customers who have taken a dependency on Spinnaker.

Initial release (1.13)

In our initial release we have enabled a core Spinnaker scenario for deploying immutable VM images – the Build, Bake, Deploy scenario.

As the scenario name suggests, there are three primary stages in the Spinnaker pipeline.

Build (labeled “Configuration” above): The build stage happens outside of Spinnaker and is used as a trigger for the following stages. It can be a Jenkins job, Travis job, or Webhook, and generates a package that will be used to create a VM image.

The build stage happens outside of Spinnaker and is used as a trigger for the following stages. It can be a Jenkins job, Travis job, or Webhook, and generates a package that will be used to create a VM image. Bake: This stage uses the package from the previous step to create an Azure managed VM image.

This stage uses the package from the previous step to create an Azure managed VM image. Deploy: Finally, the deploy stage deploys one or more Virtual Machine Scales Sets using the managed VM image from the previous step. This can be done using one of the built-in strategies like Highlander or Red/Black.

Since Spinnaker is used to deploy to multiple clouds, it has created some abstractions for common infrastructure components. In this release these abstractions map to Azure infrastructure as follows:

What’s next?

We are excited to be accepted as part of the Spinnaker open source community and will continue to invest in Spinnaker to enable other scenarios like container-based Azure Kubernetes Service (AKS) deployments, improve performance, and flexibility in infrastructure abstractions. We will publish our roadmap so keep an eye out and let us know what you think.

If you are interested in learning more about Spinnaker, or it’s already an important component in your DevOps and you would like to help us make the integration with Azure great, please reach out to us. You can connect directly with us in any of the following venues: