Bootstrapping the Continuous Pipeline

Barton Nicholls & Ed Rousseau (SimpliSafe)

Using Spinnaker to improve visibility into the continuous delivery process.

Presented at the Boston DevOps Meetup May 18 2016.

http://www.meetup.com/Boston-Devops/events/230870643/

Transcript

1. Bootstrapping the Continuous Pipeline ::By Barton Nicholls & Ed Rousseau (SimpliSafe)
3. Requirements: • Infinitely repeatable • Self serviceable • Baseline matches production • Best of class components • Low cost of maintenance • Extensible
4. Where are we now? • Infrastructure code is owned and operated by Ops • Developers are mystified by the process • Communication around infrastructure withers on the vine • Missed opportunities • Missed opportunities • Missed opportunities • Missed opportunities • More missed opportunities ………...
5. Next Steps: • Empower the end user ◦ Push button • Get out people’s ways ◦ Push button • Make it easy ◦ Push button • Free up our time ◦ Push button • Reduce animosity ◦ Push button
11. Results: Infrastructure code is still owned, secured, tested, maintained, analyzed, agonized, monitored, refactored, philosophied, demystified, renounced, revoked, refinished, reorganized and rethought by Ops With two main differences: • The conversation about infrastructure can be extended to the stakeholders without conditions - enabling changes for stakeholders becomes easy • Stakeholders only need to know what is possible, not the guts of how it’s done
12. Why Now? • Engineering team x3 in size in last 18 mo ◦ Original Vagrant, Puppet, Terraform implementation outgrown by new roles and ways of working ◦ Current team much more comfortable with AWS than at start ◦ Need for larger matrix of infrastructure variation beyond Dev - Stg - Prod • Refactor needed anyway ◦ Inheritance in Terraform scripts made it difficult to create and maintain multiple permutations of infrastructure ◦ While instances cattle, scripts were pets ◦ Code being promoted led to drift between environments (every deploy a rebuild) • Desire for Red / Black deployment capability
13. Benefits: • Easier definition and maintenance of varied environments (multiple integration and loadtest environs, variance in region, security groups, deployed mocks, spinup / spindown) • Build artifacts promoted not code ◦ Better confidence that what we tested is in the environment ◦ More easily sharable between environments ◦ Less risk of drift • Provisioning self-service ◦ Push a button not hack a script • Variations easily sharable
14. Building Blocks: • Go CD ( Thought Works : ( https://www.thoughtworks.com/go/ )) ◦ Make • Effing Package Management : ( https://github.com/jordansissel/fpm/wiki ) ◦ Package • Artifactory ( JFrog : ( https://www.jfrog.com/artifactory/ )) ◦ Store • CloudFormation ( AMZ : ( https://aws.amazon.com/cloudformation/ )) ◦ Build • Spinnaker ( NFLX&GOOGL : ( http://www.spinnaker.io/ )) ◦ Deploy