Before you begin: Read our Stages of Software Delivery Evolution Infographic to understand which stage your company currently falls into.
Seven Steps to Success:
Treat deployments as a product. Assign a product owner (ideally full-time) who is responsible for ensuring the success of Spinnaker within your organization. Just like other product managers in your company, this person will talk to internal customers, define requirements, build a project plan, articulate a product road-map, and ensure your internal customers’ success.
Achieve consensus that a deployment problem exists (1-2 weeks). You probably have a good idea of what deployment problems exist but it’s important to get consensus from the engineers on those problems, in their own words. We strongly recommend surveying your service owners and engineering managers to help determine the pain points that everyone is experiencing. It’s hard to solve a problem that no one perceives to exist. Additionally it’s good to illustrate the pain points that applications teams are experiencing today as a way to motivate teams to move to Spinnaker.
We recommend using this survey for your teams, but you may choose to use your own.
Here are some questions you might ask:
- What service do you currently work on?
- How do you deploy today?
- What pain points exist with your deployments?
- How urgent is it for you to solve this pain point?
- Are you interested in participating in an internal POC?
- What do you value more? (velocity | safety)
After you complete the survey we will help you compile the results and disseminate it across the organization as a solid starting point.
Define success metrics (1 day). Good candidates for success metrics to track are: number of deployments, time to deploy, reduction of manual steps, or improved SLA. Choose the two or three metrics most germane to your organization based on what you learn from surveying application teams and highlight those metrics as you roll out Spinnaker in production.
Define and execute on a tight proof-of-concept (1-2 weeks). Unlike other developer tools like Github or Pagerduty that can be seen as a more "personal choice", Spinnaker represents an agreement between an entire organization on how you will operate. Spinnaker enables the DevOps vision of empowering engineers to truly own their applications and deployments.
For some companies this will be a sweeping cultural and philosophical change from how you've traditionally operated. From our experience, the best way to prove that this is a better way of working is with data (see step #3 above), and the best way to quickly acquire data is by executing on a rapid POC that demonstrates success (ideally the POC takes 1-2 weeks at most).
We recommend starting with a single team and a single app being deployed to production with Spinnaker. We’ve found through working with other enterprise companies that it’s critical for the application to go all the way to production (and not just to a staging environment) to help prove that this works and that the data is real.
Choosing a right team for the POC. You probably have a good idea of what teams might make good candidates for your POC. Ideally, you find an application team that has an existing and urgent pain point with their deployment system and who is motivated and incentivized to improve it. This team will become your early evangelists and help spread the word about Spinnaker and why it’s valuable.
Choosing the right application for the POC. There are some applications better suited for Spinnaker than others. We will do an additional survey that asks application teams about their current deployment practice(s). Some questions would include:
- What external data sources (databases, API, datastores) are needed to run your app?
- How is configuration management handled for your app?
- How are data migrations (if any) managed for your app?
- How is service discovery handled within your app?
- Describe the build process and its outputs?
- What type of automated testing is built into the app?
- How is the system configured?
Ideally we find an application that has few external data sources, simple and smaller configuration management, no data migrations, ELB based service discovery, and a clean build process which has simple output like a WAR file(Web application ARchive) which would make a great POC candidate.
Build a case study (1 week). When the POC is completed, compile the results and present them to executives for additional buy-in and support, and also to the next set of application teams to identify teams for the beta launch.
Beta launch (1 month). The beta launch will open up Spinnaker on-boarding to a larger group of teams. If the POC team can be seen as the center of the circle then the beta is the next concentric circle outward; as such, it will include additional features and functionality. Since you already surveyed the application teams in Step #2, you know who you should approach first for participation in the beta.
Hopefully, by now your POC has generated enough buzz that beta customers are banging on your door to get in, but if not you can use your case study from Step 5 to help sell them.. In order to execute on the beta launch successfully, you’ll need to create a more robust project plan and build the functionality needed to support the larger set of customers. Set a hard deadline to launch the beta and rally your platform team around this date to make sure you hit it. Your product owner (Step 1) will be largely responsible for making sure you hit this date, on-board, and train the new teams successfully.
General availability (1-3 months). After the beta launch is completed, you’ll have even more data and case studies to celebrate. This is a good opportunity to revise your case study and present your results to executives and engineering leaders once more. You’ll also work on the final set of requirements for a GA launch. Again, set a date and assign your PM the owner for ensuring success.
Training and Support Resources
Application team survey. Here’s a link to a survey we recommend sending to application team owners to determine if they are a good fit for the POC, Beta, or GA launch.
Armory Spinnaker Documentation. We’ve developed administrative documentation (for platform teams) and user documentation (for application teams). Today, these guides are private, but we’re launching them on our website as part of our next sprint. Here’s a screenshot of one of the guides and another screenshot of the final look/feel that will be published soon.
Training. Armory provides two types of training for all of our customers: Administrative and User training. Administrative training should be attended by your platform team and includes information on how to operate, upgrade, and troubleshoot Spinnaker in production. User training should be attended by your application teams and provides guidance on best practices and how to use Spinnaker effectively.