Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Automated Deployment at Auto Trader:
 How We Pu...

Automated Deployment at Auto Trader:
 How We Put Developers In Control & What We Learned

This is a talk I delivered about Automated Deployment at Auto Trader for a DevOps Edinburgh meet up on Monday 7th December at the Skyscanner offices in Edinburgh.

It covers covers:

• Auto Trader’s deployment history
• Our project which delivered control of deployment to developers
• What we learned from the experience
• Our in-progress product which will be the future of deployment at Auto Trader

Mark Crossfield

December 07, 2015
Tweet

More Decks by Mark Crossfield

Other Decks in Technology

Transcript

  1. AUTOMATED DEPLOYMENT AT AUTO TRADER:
 HOW WE PUT DEVELOPERS IN

    CONTROL & WHAT WE LEARNED MARK CROSSFIELD, DECEMBER 2015
  2. About Auto Trader and me Some deployment history Automated Deployment

    v1: Pipelines! What did we learn? Automated Deployment v2: Private Cloud STRUCTURE
  3. LOTS OF PEOPLE have contributed to this over the course

    of years Although I’m telling the story…
  4. 4 MILLION PAGE VIEWS / HR At peak users generate

    data taken from Google Analytics
  5. Multi faceted & geographic search over ~480k vehicles Large volume

    of traffic Large number of applications behind the scenes Lack of vehicle sale visibility masks business metrics CORE CHALLENGES
  6. 2 x data centre suites each containing: F5 BIG-IP DNS

    Global Traffic Management F5 Local Traffic Management ~2,400 virtual servers using VMware ~200 HP Blades NetApp Storage INFRASTRUCTURE
  7. Java: Spring Boot / Dropwizard Solr, Oracle, Mongo, MySQL, SQL

    Server, Vertica Jetty / JBoss Apache CentOS STACK
  8. 2007: Copied .war files 2008: Standardised script built RPMs, Perl

    deployment script, hired team of release engineers, VMware 2009: Redeveloped autotrader.co.uk built own RPM, introduced Cruise / Go CD 2010: Another project builds own RPM, release engineers absorbed 2011: Further projects build own RPM 2013: New CEO DEPLOYMENT HISTORY
  9. HAVE A CLEAN CONTRACT WITH THE UNDERLYING OPERATING SYSTEM, OFFERING

    MAXIMUM PORTABILITY BETWEEN EXECUTION ENVIRONMENTS http://12factor.net/
  10. THE TWELVE-FACTOR APP STORES CONFIG IN ENVIRONMENT VARIABLES… ENV VARS

    ARE EASY TO CHANGE BETWEEN DEPLOYS…, THEY ARE A LANGUAGE—AND OS—AGNOSTIC STANDARD. http://12factor.net/
  11. ! Config in the hands of developers ! Deployments are

    repeatable ! Deployments are faster ! Less people tied up ! No longer constrained by release slots RECAP
  12. # Senior Leadership Support # Starting with frequent deployers #

    Piloting with flexible team # Automating existing processes # Building tools and build plugins # Focussed multi skilled team with CI mindset THINGS WHICH HELPED
  13. Decouple devs from infrastructure using a clean API Make deployments

    easy and visible Make deployments faster Reduce config drift Make infrastructure change visible Flow regular updates through teams’ pipelines Facilitate emergency patches Remove innovation bottlenecks GOALS
  14. Get leadership buy in Dedicate people with the right skills

    and attitude Involve your customers & shout about progress Focus on the MVP Look for shortcuts Reorganise around products Keep it simple, stupid CONCLUSIONS
  15. Resources Continuous Delivery
 Reliable Software Releases through Build, Test, and

    Deployment Automation by Jez Humble and David Farley http://www.amazon.co.uk/dp/0321601912 A manifesto for applications running on Heroku, and applicable as a set of best practices for cloud native applications with some great wisdom http://12factor.net/ Berkshelf: Chef Cookbook packaging (part of Chef DK) http://berkshelf.com/ https://www.go.cd/ https://downloads.chef.io/chef-dk/ Scaling Agile @ Spotify http://bit.ly/SquadsAndTribes