50 production deployments a day, at least
•Télécharger en tant que PPTX, PDF•
1 j'aime•1,838 vues
The document discusses continuous delivery and DevOps practices for software development. It notes that the objective is to achieve 50 production deployments per day with no service impact through automation, continuous integration, testing pipelines, and a culture of collaboration and shared responsibility across functions. It emphasizes that culture and people are more important than processes and tools for successful continuous delivery.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 50 production deployments a day, at least
Similaire à 50 production deployments a day, at least (20)
Plus de Oscar Renalias
Plus de Oscar Renalias (10)
Dernier
Dernier (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
Notes de l'éditeur
- 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.