50 production deployments a day, at least
•1 like•1,838 views
Report
Share
Download to read offline
Companies like Flickr, Amazon and Etsy are doing hundreds of deployments a day, so why can't we?
Recommended
More Related Content
What's hot
What's hot(20)
Similar to 50 production deployments a day, at least
![[Webinar] Test First, Fail Fast - Simplifying the Tester's Transition to DevOps](https://cdn.slidesharecdn.com/ss_thumbnails/testfirstfailfastfinal-170323164615-thumbnail.jpg?width=384&fit=bounds)
Similar to 50 production deployments a day, at least(20)
![[Webinar] Test First, Fail Fast - Simplifying the Tester's Transition to DevOps](https://cdn.slidesharecdn.com/ss_thumbnails/testfirstfailfastfinal-170323164615-thumbnail.jpg?width=768&fit=bounds)
![From 0 to DevOps in 80 Days [Webinar Replay]](https://cdn.slidesharecdn.com/ss_thumbnails/slideswebinarfrom0todevopsin80days-161104194455-thumbnail.jpg?width=768&fit=bounds)
More from Oscar Renalias
More from Oscar Renalias(10)
Recently uploaded
Recently uploaded(20)
50 production deployments a day, at least
- 1. www.techarchday.fi www.techarchday.fi 50 production deployments a day, at least Oscar Renalias Senior Technology Architect v10
- 3. 2009 2014 2015 50+ deploys per day 10 deploys per day Deploys to production every 11.6 seconds
- 6. QA & Test Operate Best Guess Design & Build
- 7. Design & Build QA & Test Operate Best Guess Feedback Experiments
- 8. QA & Test Operate Best Guess Design & Build 1 YEAR6 MONTHS1 MONTH2 WEEKS1 WEEKS1 DAY1 HOURMINUTES
- 9. Run over 200 concurrent experiments on any given day http://www.exp-platform.com/Pages/ControlledExperimentsAtLargeScale.aspx
- 11. Our objective: 50 deployments a day with no service impact
- 14. SAY CONTINUOUS IMPROVEMENT ONE MORE TIME
- 23. Value Released Time Guessed Well Guessed Badly
- 24. Value Released Time Value Stream Idea Value Value Stream Idea Value Value Stream Idea Value Rapid Feedback Optimise
- 28. CI – what good looks like… Changes constantly pushed to version control Fixing a broken build is always the priority Nobody goes home on a broken build
- 30. Pipeline! Pipeline! Pipeline! Build Static Analysis ST Regression Build Static Analysis ST Regression Build Static Analysis ST Regression Performance Test Security Test
- 31. Pipeline! Pipeline! Pipeline! Build Static Analysis ST Regression Build Static Analysis ST Regression Build Static Analysis ST Regression Performance Test Security Test Effort and schedule Test Phase Comprehensive Fast
- 32. Pipeline! Pipeline! Pipeline! Build Static Analysis ST Regression Build Static Analysis ST Regression Build Static Analysis ST Regression Performance Test Security Test Effort and schedule Test Phase Pre-commit 1 min Component 1 hour Acceptance 4-8 hours Commit 10 mins
- 33. Pipeline! Pipeline! Pipeline! Build Static Analysis ST Regression Build Static Analysis ST Regression Build Static Analysis ST Regression Performance Test Security Test Effort and schedule Test Phase Stop the assembly line!
- 35. THEY WANTED MORE AGILITY, SO WE SOLD THEM $2M IN DEVOPS TOOLS
- 36. Continuous Delivery Principles Each check-in is a candidate production release The same processes and tools in ALL environments A failure at any stage stops the production line It’s not about the tools!
- 38. I CAN HAZ CONTINUOUS DELIVERY?
- 39. Fail-fast Microservices Metrics and Logs Independently deployable and scalable components Failure is unavoidable. Deal with it. Proactive monitoring
- 41. RELEASE TIME!
- 42. Oscar’s unscientific observations of release failures Human failures
- 44. Pets vs Cattle
- 46. Build Static Analysis ST Regression Performance Test Security Test Deployment Test & QA
- 47. Automation Infrastructure as code Test, test, test Eliminate the human factor
- 49. WORKED FINE IN DEV OPS PROBLEM NOW
- 50. Smooth Collaboration Fully Embedded Infrastructure-as-a-Service DevOps as a Service Separate DevOps Team DevOps Culture: Which one is right for you? Source: http://www.devopstopologies.com
- 51. FIRED YOUR EXISTING TEAM AND REPLACED THEM WITH A DEVOPS TOOL? THAT MUST BE GOING WELL
- 52. Organisation and Culture Align to business priorities Quality is everybody’s responsibility Define your own DevOps Culture People over processes and tools
Editor's Notes
- Deployment every 11.6 seconds is equivalent to (24*60*60)/11.6 = 7448 deployments/day
- Accelerating value delivery.
- Do I need you to do 50 deploymens a day? No. But you need to desing your DevOps capabilities as if you have to.
- Finally perhaps a more subtle problem is that when releases are infrequent call them whatever you want, smaller releases take place in between These are usually harder to test, harder to track, they cause merge work and they make main releases much harder
- Finally perhaps a more subtle problem is that when releases are infrequent call them whatever you want, smaller releases take place in between These are usually harder to test, harder to track, they cause merge work and they make main releases much harder
- When a deployment fails, 95% of the time is due to human error
- Pets are cared for, and taken to the vet when they get ill. When cattle are sick, they’re shot. Same applies for infrastructure.
- Automate everything
- Smooth Collaboration This is the ‘promised land’ of DevOps: smooth collaboration between Dev teams and Ops teams, each specialising where needed, but also sharing where needed. There are likely many separate Dev teams, each working on a separate or semi-separate product stack. My sense is that this Type 1 model needs quite substantial organisational change to establish it, and a good degree of competence higher up in the technical management team. Dev and Ops must have a clearly expressed and demonstrably effective shared goal (‘Delivering Reliable, Frequent Changes’, or whatever). Ops folks must be comfortable pairing with Devs and get to grips with test-driven coding and Git, and Devs must take operational features seriously and seek out Ops people for input into logging implementations, and so on, all of which needs quite a culture change from the recent past. Fully Shared Ops Reponsibilities Where operations people have been integrated in product development teams, we see a Type 2 topology. There is so little separation between Dev and Ops that all people are highly focused on a shared purpose; this is arguable a form of Type 1 (Dev and Ops Collaboration), but it has some special features. Organisations such as Netflix and Facebook with effectively a single web-based product have achieved this Type 2 topology, but I think it’s probably not hugely applicable outside a narrow product focus, because the budgetary constraints and context-switching typically present in an organisation with multiple product streams will probably force Dev and Ops further apart (say, back to a Type 1 model). This topology might also be called ‘NoOps‘, as there is no distinct or visible Operations team (although the Netflix NoOps might also be Type 3 (Ops as IaaS)). Where operations people have been integrated in product development teams, we see a Type 2 topology. There is so little separation between Dev and Ops that all people are highly focused on a shared purpose; this is arguable a form of Type 1 (Dev and Ops Collaboration), but it has some special features. Organisations such as Netflix and Facebook with effectively a single web-based product have achieved this Type 2 topology, but I think it’s probably not hugely applicable outside a narrow product focus, because the budgetary constraints and context-switching typically present in an organisation with multiple product streams will probably force Dev and Ops further apart (say, back to a Type 1 model). This topology might also be called ‘NoOps‘, as there is no distinct or visible Operations team (although the Netflix NoOps might also be Type 3 (Ops as IaaS)). Ops as Infrastructure-as-a-Service For organisations with a fairly traditional IT Operations department which cannot or will not change rapidly [enough], and for organisations who run all their applications in the public cloud (Amazon EC2, Rackspace, Azure, etc.), it probably helps to treat Operations as a team who simply provides the elastic infrastructure on which applications are deployed and run; the internal Ops team is thus directly equivalent to Amazon EC2, or Infrastructure-as-a-Service. A team (perhaps a virtual team) within Dev then acts as a source of expertise about operational features, metrics, monitoring, server provisioning, etc., and probably does most of the communication with the IaaS team. This team is still a Dev team, however, following standard practices like TDD, CI, iterative development, coaching, etc. The IaaS topology trades some potential effectiveness (losing direct collaboration with Ops people) for easier implementation, possibly deriving value more quickly than by trying for Type 1 (Dev and Ops Collaboration) which could be attempted at a later date. For organisations with a fairly traditional IT Operations department which cannot or will not change rapidly [enough], and for organisations who run all their applications in the public cloud (Amazon EC2, Rackspace, Azure, etc.), it probably helps to treat Operations as a team who simply provides the elastic infrastructure on which applications are deployed and run; the internal Ops team is thus directly equivalent to Amazon EC2, or Infrastructure-as-a-Service. A team (perhaps a virtual team) within Dev then acts as a source of expertise about operational features, metrics, monitoring, server provisioning, etc., and probably does most of the communication with the IaaS team. This team is still a Dev team, however, following standard practices like TDD, CI, iterative development, coaching, etc. The IaaS topology trades some potential effectiveness (losing direct collaboration with Ops people) for easier implementation, possibly deriving value more quickly than by trying for Type 1 (Dev and Ops Collaboration) which could be attempted at a later date.