Sep 1, 2020 by Ryan Cartwright
At Upside, we take pride in our deployment culture. We ship new versions of code multiple times per day through our various environments powered by AWS and Kubernetes. We run an infrastructure stack that leverages the powerful microservice architecture pattern that sees our applications broken up into smaller segments that each do one thing, but do it very well. Thanks to our applications being loosely coupled, we feel safe deploying fast and deploying often due to blast radius being minimized.
Half the battle of implementing true CI/CD is already won at Upside due to our awesome engineering management and teams being fully supportive of the culture. The other half of the battle is implementing it from a technical standpoint. A big portion of this effort involves weighing the pros and cons of the many tools out there in regards to your specific CI/CD needs. This is very important; just because there is a shiny new item out there, doesn’t necessarily mean that it is a one size fits all for everyone. To quote the late American psychologist Abraham Maslow, “If all you have is a hammer, everything looks like a nail”.
Let’s take a step back to fully flesh out what CI/CD means, because it can help us start to visualize the problem that we believe Spinnaker helps us to solve.
CI/CD stands for “Continuous Integration and Continuous Delivery/Deployment”:
Continuous Integration deals with the culture of integrating code into a shared repository multiple times per day. Often times, automated tests are run on every merge, and artifact builds are kicked off. In our case at Upside, upon every merge to master, we run tests and then build and push a new Docker image that represents that version of the code.
These are actually two different cultures and the difference between the two can really elevate a team’s ability to roll new services out. Continuous Delivery deals with automating the process of deploying artifacts into your environments. Typically this involves an automated deployment into dev, in which some sort of a manual judgement is needed to then deploy that artifact to later environments, and then finally ending in a deployment to production. Continuous Deployment takes this a step further and removes these manual judgements. This can be a heavy undertaking due to engineers having to write and rely on automated testing which will dictate if the code should be promoted to the next environment or not. Another roadblock to Continuous Deployment is finding the right tooling that balances out-of-the-box functionality but still leaving enough room for customization. At Upside, we are making the push to get to full Continuous Deployment, and Spinnaker is what is enabling us to get there.
Now that we can start to see what the true nature of Continuous Deployment looks like, let’s talk about the open-sourced tool developed by Netflix called Spinnaker that helps to enable it.
Also, a disclaimer that this article is less of a “how to use Spinnaker”, and more of a high level “how we are leveraging Spinnaker at Upside”. If you are interested in how to get started, check out the Spinnaker docs on how to install it and create your first pipeline.
In a nutshell, Spinnaker is an open-sourced and self-hosted platform that allows you to quickly build out deployment pipelines. It is also multi-cloud in that you can easily deploy with built in functions to AWS, Azure, GCP, and Kubernetes to name a few. For example, need a stage in your pipeline to deploy a Helm chart to a Kubernetes cluster? Easy, there’s a built in function for this. Oh, but it needs to be a Canary deployment and analysis? Done, Spinnaker comes with that built in functionality as well. At Upside, these built in functionalities are a big reason of what sold us on Spinnaker — could you imagine scripting these in Jenkins?
Above is a somewhat simple deployment pipeline that we use here at Upside, but still nonetheless complex. I won’t get into the specifics of what each stage is doing, but the pipeline is triggered either manually in the Spinnaker UI, or triggered on a new image hitting a Docker registry. The pipeline then uses Helm to bundle our Kubernetes spec files into an artifact that can be used downstream by our Deploy stage.
Then we have a manual approval stage that is dynamically enabled if our Run Tests stage sees something in our newly deployed resources that would need human intervention for. This manual approval has 3 options:
Previously at Upside, we had continuous deployment to our Dev environment in that upon merge to master, Jenkins would use Helm to deploy to Dev. It was then up to the engineering teams to trigger this Jenkins job to promote that to our Staging environment, and then finally to Prod. Spinnaker helps improve upon this in the following ways:
Spinnaker has given our team more runway to build out complex and robust deployment pipelines with ease. With more robust deployment pipelines, we are able to not inch, but begin running towards our goal of true Continuous Deployment. With Continuous Deployment, we can further increase not only the velocity of our deployments, but also our confidence in them.
Introducing Quick Spin One of the most common challenges that organizations face when implementing a continuous deployment strategy is the time and focus that it takes to set up the tools and processes. But a secure, flexible, resilient and scalable solution is available right now. Want to see if it’s the right tool for your […]
Read more →
Spinnaker is the most powerful continuous delivery tool on the market. DevOps engineers and developers recognize this power and are looking to use Spinnaker as a foundational tool in their Continuous Integration and Continuous Delivery (CI/CD) process for hybrid and multi-cloud deployments. Such a powerful, expansive open source tool needs expertise within your organization to […]
Read more →
Today, Armory is excited to announce the availability of the GitHub Action for Armory Continuous Deployment-as-a-Service. GitHub is where developers shape the future of software. After a developer writes and tests their code in GitHub, it must be deployed. Armory’s GitHub Action for Continuous Deployment-as-a-Service extends the best-in-class deployment capabilities to Kubernetes. CD-as-a-Service enables declarative […]
Read more →