Anúncio
Starting and Scaling DevOps
26 de Jan de 2017•0 gostou•219 visualizações
1 gostaram
Seja o primeiro a gostar disto
mostrar mais
visualizações
Vistos totais
0
No Slideshare
0
De incorporações
0
Número de incorporações
0
Baixar para ler offline
Denunciar
Software
More and more companies worldwide are excited about DevOps and the many potential benefits of embarking on a DevOps transformation. The challenge many of them are having, however, is figuring out where to begin and how to scale DevOps practices over time. These challenges can be especially daunting in large enterprises. In this webinar we will discuss a maturity model for framing your transformation, then focus on analyzing your deployment pipeline and identify existing inefficiencies in software development and deployment.
Jules Pierre-LouisSeguir
Anúncio
Anúncio
Anúncio
Recomendados
Enterprise DevOps: Crossing the Great Divide with DevOps TrainingITpreneurs
Transform Agile Development With Practical DevOpsGaurav Sharma
Effective devops Mohammed Aboullaite
Devops & Agility - Build the Culture, Get the Tools, Win the Day - Dundee Tec...David Walker
Fundamental Concepts of DevOpsKiril Serebnik
Continuous Delivery e-bookZend by Rogue Wave Software
Starting and Scaling DevOps
- #JenkinsWorld Starting and Scaling DevOps in the Enterprise Gary Gruver Brian Dawson
- Agenda • Defining DevOps • Quantify DevOps in 4Qs • Starting and Scaling DevOps • Q&A
- Speakers Gary Gruver President Gruver Consulting LLC Brian Dawson DevOps Evangelist CloudBees Inc
- Defining DevOps
- Gene Kim Quote This is my personal definition: I would define DevOps by the outcomes. In my mind, DevOps is those set of cultural norms and technology practices that enable the fast flow of planned work from, among others, development, through tests into operations while preserving world class reliability, operation and security. DevOps is not about what you do, but what your outcomes are. So many things that we associate with DevOps fits underneath this very broad umbrella of beliefs and practices—which of course, communication and culture are part of them. “ © Gruver Consulting
- Software changes continuously deployed to live production Continuous Deployment Software changes continuously delivered to stakeholders in any environment Continuous DeliveryContinuous Integration Automated commit, build and testing of code in the development environment User FeedbackRapid Changes Discipline AGILE An incremental approach to identifying, prioritizing, and coordinating feature development Development Production / Prod-like Live Production Env.Stage Release Deploy Monitor Upstream (left) Downstream (right) Define Plan Code Commit Build Non-Func Test Scan Integrate Int. Test Package Deploy Acct. Test Load Test Change Mgt. Production Bugs Agile, CI, Continuous Delivery and DevOps 6 DevOps → Culture approach, supported by practices
- Quantify DevOps in 4Qs
- ©2016CloudBees,Inc.AllRightsReserved 8 SECOPSMICROSERVICES GIT JENKINS GITLAB SCRUM DEVOPS CONTINUOUS IMPROVEMENT MICROSERVICES SC GIT PERFORCE NEXUS SCRUM SCRUM XP LEAN CONTINUOUSDELIVERY CONTINUOUSDELIVERY CONTINUOUS DEPLOYMENT VM TEST AUTOMATION BLAZE METER NEW RELIC STOP THE LINE DevOps Word Soup 8
- ©2016CloudBees,Inc.AllRightsReserved 9 DevOps Word Soup DEVOPS SECOPS CONTINOUS INTEGRATION CONTINUOUSDELIVERY ONTINUOUSDELIVERY MICROSERVICES MICROSERVICES VM SCM TEST AUTOMATION GIT GIT PERFORCE JENKINS NEXUS GITLAB BLAZE METER NEW RELIC SCRUM SCRUM SCRUM XP LEAN STOP THE LINE 9
- ©2016CloudBees,Inc.AllRightsReserved 10 SIMPLE CAN BE HARDER THAN COMPLEX: YOU HAVE TO WORK HARD TO GET YOUR THINKING CLEAN TO MAKE IT SIMPLE. BUT IT’S WORTH IT IN THE END BECAUSE ONCE YOU GET THERE, YOU CAN MOVE MOUNTAINS. -Steve Jobs 10
- ©2016CloudBees,Inc.AllRightsReserved 11 WHERE ARE WE? WHERE ARE WE GOING? HOW DO WE GET THERE? SIMPLIFY 11
- X-Axis: SDLC Phases 12 Upstream Downstream OperateDefine Plan Code Build Integrate Test Release Deploy
- X-Axis: SDLC Phases 13 Agile Upstream 33% Agile Downstream 13% OperateDefine Plan Code Build Integrate Test Release Deploy
- Y-Axis: Levels of adoption 14 Agile Upstream 33% Agile Downstream 13% Enterprise Agile Upstream 22% Enterprise DevOps 10% TeamWorkgroupEnterprise Define Plan Code Build Integrate Test Release Deploy Operate
- The Destination 15 Agile Upstream 33% Agile Downstream 13% Enterprise Agile Upstream 22% Enterprise DevOps • Innovate faster • Respond to market • Gain competitive advantage • Increased productivity • Employee satisfaction and retention TeamWorkgroupEnterprise Define Plan Code Build Integrate Test Release Deploy Operate
- The DevOps Trinity and the Chasms 16 Upstream Downstream People & Culture Process & Practices Tools & Technology Agile, Scrum, Kanban PMBOK, ITIL, Waterfall Point Tools, Grassroots, Rapid Change Move Fast, Innovate Maintain Quality Stability, Uptime Enterprise Class, Corp. Procurement, Stable Define Plan Code Build Integrate Test Release Deploy Operate
- CloudBees 4Qs of DevOps maturity 17 Quadrant 1: Team-level Agile Quadrant 2: Team-level CD Quadrant 3: Enterprise Agile Quadrant 4: Enterprise DevOps TeamWorkgroupEnterprise Define Plan Code Build Integrate Test Release Deploy Operate
- The Path To DevOps Q1: Team-level Agile Q3: Enterprise Agile Q4: Enterprise CD Q2: Team-level CD • Mature CI practices for some teams • Some tools federation and standardization • Development disconnected from delivery • Often Water-scrum-fall approach • Mature CD for some teams • Improved tools standardization • Development connected to delivery • Some teams release in weeks, days or hours • Mature CI practices for most-to-all teams • Elastic CI-as-a-service • Tools centralization and standardization • Increased developer productivity • Mature CD on most-to-all teams • Elastic, Internally-Managed CD-as-a-Service • Development and delivery tools centralization and standardization • Most teams release in weeks, days or hours CloudBees 4Qs of DevOps maturityTeamWorkgroupEnterprise Define Plan Code Build Integrate Test Release Deploy Operate
- The Trinity and the Chasms 19 Upstream Downstream People & Culture Process & Practices Tools & Technology Agile, Scrum, Kanban PMBOK, ITIL, Waterfall Point Tools, Grassroots, Rapid Change Move Fast, Innovate Maintain Quality Stability, Uptime Enterprise Class, Corp. Procurement, Stable Define Plan Code Build Integrate Test Release Deploy Operate
- Poll Question Which quadrant is your organization in? • Quadrant 1 – Team-Level Agile • Quadrant 2 – Team-Level CD • Quadrant 3 – Enterprise Agile • Quadrant 4 – Enterprise CD or DevOps • Quadrant 0 – None (Legacy, Waterfall)
- Starting and Scaling DevOps
- FW no longer a bottleneck for the business Development costs reduced from $100M/yr. to $55M/yr. 140% increase in the number of products under development Capacity for innovation increased from ~5% to ~40% © Gruver Consulting
- © Gruver Consulting
- © Gruver Consulting
- Gene Kim Quote This is my personal definition: I would define DevOps by the outcomes. In my mind, DevOps is those set of cultural norms and technology practices that enable the fast flow of planned work from, among others, development, through tests into operations while preserving world class reliability, operation and security. DevOps is not about what you do, but what your outcomes are. So many things that we associate with DevOps fits underneath this very broad umbrella of beliefs and practices—which of course, communication and culture are part of them. “ © Gruver Consulting
- © Gruver Consulting Business Ideas Developer Production Monitoring Environment Testing
- © Gruver Consulting Environment Testing Developer Business Ideas Production Monitoring
- © Gruver Consulting Environment Testing Developer Business Ideas Production Monitoring
- © Gruver Consulting MonitoringMonitoring Environment Testing Developer Business Ideas Production Monitoring
- © Gruver Consulting Monitoring How Long Frequency Issue Source Environment Testing Developer Business Ideas Production Planning Capacity Requirements Inventory % Reworking % Expected Results Deploy Time & Effort Source & Number of New Issues New Issues Cycle Time Batch Size Repeatability Branch Time Approval Times
- © Gruver Consulting Segmenting Tightly Coupled Loosely Coupled Non Business Critical
- © Gruver Consulting Tightly Coupled Architecture A B C E F G H I J D K L M Service Virtualization Service Virtualization
- © Gruver Consulting Segment with SV A B C D E F G H I J K L M Subsystem I Subsystem II Subsystem III Service Virtualization Service Virtualization
- © Gruver Consulting Subsystem I Deployment Pipeline D C B AA B C D Phase 2 & 3 A B C D
- Subsystem I Subsystem II Subsystem III Stage 3 Stage 4 BAT Stage 6Stage 5 Regression Production Full System Deployment Pipeline
- Subsystem I Subsystem II Subsystem III Stage 3 Stage 6Stage 4 BAT Stage 5 Regression Production Full System Deployment Pipeline
- © Gruver Consulting Subsystem I Subsystem II Subsystem III Stage 3 Stage 6Stage 4 BAT Stage 5 Regression Production 4 Hours 16 Hours 3 Hours 2 Weeks 18 Hours 1 Week 3 Days 1 Day to deploy 2 Days to test 3 Days Cycle Time and Batch Size Map
- © Gruver Consulting Source of Issue Slide Subsystem II Stage 5 Regression Subsystem III Stage 3 Stage 6Stage 4 BAT Production Subsystem I Code Environment Test Deploy
- Leadership vs Empowerment Specialization vs Generalist Push to production Green builds & Quality Gates © Gruver Consulting
- Poll Question Where are you on your CD/DevOps journey? • Investigating • Planning • Marching along • We’re there • None of the above
- Questions?
Notas do Editor
- Introduction Always introduce this way because I truly believe this is the potential impact
- This is going to require eliminating waste and improving efficiencies Types of work: New/Unique, repetitive, triage Getting everyone on the same page & where to start DP Agenda 12Min Basic DP 1 Dev Metrics for aligning starting point and progress Scaling to a Dev team DevOps appr. for small teams DevOps appr. large tightly coupled teams Close with impacts of changes
- Build 1: (Software Delivery Cycle) Regardless of how your company approaches software development and delivery, it includes fundamental tasks from defining requirements, to coding to managing builds, to integration testing, to packaging distributions, deploying to testing or production, monitoring and re-iterating all over again. Whatever specific steps you take, these are the sequential tasks of software delivery. Typically each stage is deployed to defined development, staging and productions environments. The tasks we focus on throughout are referred to upstream, and sometime “left” in the delivery flow or downstream, or “right” based on where the typically occur in the process. Build 2: (Rapid Changes driven by Use Feedback) The biggest driver for a need for faster delivery is the ever-increasing demand from users and consumers (depending on our business type), who are placing demands on the business to innovate and compete to provide better experiences and services. Not only do these changes need to be implemented quickly, they have to be delivered with levels of quality that assure continuous user satisfaction. Methods to collect detailed feedback downstream must be continually fed back into upstream development Build 3: (Agile) Agile delivery and processes have become a standard incremental approach to building software faster, specifically targeting user needs . Whether you are in a highly regulated insurance or financial industry, or a fast moving start up, you have likely adopted some agile approach. But while agile is a predominant approach to software delivery, it comes with a fair set of challenges associated with many, fast moving tasks that must span teams and stages. Build 4: (Continuous Integration) 10 years ago, Continuous Integration entered the scene when our CTO, Kohsuke Kawaguchi, created Jenkins to address the speed problem with automation. This allowed code that individuals and small teams were developing to be put into a framework to compresses repetitive and mundane tasks like commits, builds & unit tests. Without question, Jenkins is the defacto standard for continuous integration, with millions of users and projects across the world. Build 5: (Continuous Delivery) Today, Continuous Delivery is the next step to maturing the software delivery process, encompassing Continuous Integration to move the discrete tasks that were automated for developers and moving further down the delivery chain. Teams are able to confidently take the software coming out of development and have it ready deploy and run state for any stakeholder across the your organization. This doesn't always mean going as far as deployment into live production – that is decision based on your business needs - but you can confidently assure that the code is continuously delivered in a pipeline – ready for QA – whether internal or with third party partner – usability and acceptance testers - or to beta users release - and yes it may even deployed into live production. Build 6: (Continuous Deployment) Continuous delivery is NOT ALWAYS about delivering to live users, but if you do have continuous deployment needs - as many online retails and internet-only businesses like Google and Netflix do - then Continuous Delivery is THE necessary path to get to that objective. Build 6: (DevOps) When all this comes together, what it enables is a set a processes and technologies that allow you to realize DevOps – which makes continuous “everything” a reality for your business.
- DevOps is associated with a number of tools technologies, and practices Most are important to apply or at least understand Frequently organizations get mired in the details Frequently teams lean wrongly on a specific dogmatic practice This results in losing site of the “best fit” goal Can inhibit progress and result in “overload”, or analysis paralysis
- This results in losing site of the “best fit” goal Can inhibit progress and result in “overload”, or analysis paralysis
- I have discovered, in practice that… If you simplify the problem space, you reduced noise, and accelerate progress
- To this end, when approaching a DevOps transformation it is best to simplify… Consider the transformation a journey you plan to take. Befor you do ask 3 simple questions. Where are we? What is our current state, problems, stregnths, etc. Your starting point Where are we going? Your destinations What to you seek to achieve what is practical to achieve? How do we get there? What are the major steps (or roads) we will take to get there? In what order?
- First we will establish the X-axis for the matrix composed of our Quadrants The X-Axis is: Focused on the SDLC Can represent a agile or non-agile team All development has some form of Define, Plan, Code, Build, Integrate, Release, Deploy (or install), and Operate But separated into to halves, Agile Upstream Practice of agile definition, planning and development methods such as Scrum, Kanban, Continuous Integration etc. Greater than 33% of organizations claim to have implemented Agile Upstream Processes Benefits include…faster feedback, less code defects, better management of work The other half is Agile Downstream Covers the integrate test, release, deploy part of the process Include practices such as automated testing, continuous delivery, and continuous deployment Only 13% of organizations practice this Next slides will look into why this is an issue
- First we will establish the X-axis for the matrix composed of our Quadrants The X-Axis is: Focused on the SDLC Can represent a agile or non-agile team All development has some form of Define, Plan, Code, Build, Integrate, Release, Deploy (or install), and Operate But separated into to halves, Agile Upstream Practice of agile definition, planning and development methods such as Scrum, Kanban, Continuous Integration etc. Greater than 33% of organizations claim to have implemented Agile Upstream Processes Benefits include…faster feedback, less code defects, better management of work The other half is Agile Downstream Covers the integrate test, release, deploy part of the process Include practices such as automated testing, continuous delivery, and continuous deployment Only 13% of organizations practice this Next slides will look into why this is an issue
- The Y-axis: Represents adoption of agile-upstream and downstream across the enterprise or at scale Broken down into team->work group adoption and workgroup to enterprise. Definition of a “workgroup” or even a team may differ by organization Only a subset of those that have implemented agile-upstream have scaled it. When considered with those that implemented downstream….. As studies show only a select few organizations of implemented enterprise devops, practiciing agile-upstream and downstream at scal
- For organizations that connect upstream and downstream, and scale that to the enterprise: Can achieve DevOps and its benefits: Innovate faster Respond to market Gain competitive advantage Increased productivity Employee satisfaction and retention Often overlooked, but privately cited by many customers Leads to many of the other benefits For those interested in the bottom-line, all of these can lead to reduced-cost and/or increase revenue So why hasn’t everybody done this? [next slide]
- Implementing DevOps requires connecting multiple stake holders, often across organizations other boundaries… On th planes of People or Culture Praces and practices Tools and technology However this present what we call the Chasms, seperations between upstream and downstream, and between teams and the enterprise. Examples are: [see slide](TBC)
- These chasms, and the areas of each axis which they separate, which are supported by real data and experience, represent the Quadrants of maturity. Quadrant 1, Team-Level Agile Quadrant 2, Team-Level Continuous Delivery Quadrant 3, Enterprise Agile Upstream Quadrant 4, Enterprise DevOps I often consider this just DevOps. CD can be implemented and team-level, but DevOps requires organization wide implementation Each of the quadrants can be described, by a set of characteristics found in companies in each of the Quadrants. [next slide]
- Implementing DevOps requires connecting multiple stake holders, often across organizations other boundaries… On th planes of People or Culture Praces and practices Tools and technology However this present what we call the Chasms, seperations between upstream and downstream, and between teams and the enterprise. Examples are: [see slide](TBC)
- 1st order effect DevOps 100s vs 10s Lack of alignment
- Right way first Marketing faster execution Dev Push into production Millennial Release Everything under version control Ops feature toggles working closely with Dev on scripts Exec stock price and bonus Aligned top to bottom, Everyone excited what could possible go wrong 10 Min
- All the right parts BUT Doesn’t look or work like and elephant DevOps face plant
- This is going to require eliminating waste and improving efficiencies Types of work: New/Unique, repetitive, triage Getting everyone on the same page & where to start DP Agenda 12Min Basic DP 1 Dev Metrics for aligning starting point and progress Scaling to a Dev team DevOps appr. for small teams DevOps appr. large tightly coupled teams Close with impacts of changes
- Basic flow Simple process what could go wrong
- What can go wrong at each step Business Idea Waterfall planning too much inventory Lean JIT (20 to 5%) Env (250 day story) Consistency SE, SD, automation, cloud Testing stage Cycle time repeatability branch time Approval times (approval time story) Prod deploy time and effort (launch calls story) Monitoring New issues (IE8 short story)
- What can go wrong at each step Business Idea Waterfall planning too much inventory Lean JIT Env (250 day story) Consistency SE, SD, automation, cloud Testing stage Cycle time repeatability branch time Approval times (approval time story) Prod deploy time and effort (launch calls story) Monitoring New issues (IE8 short story)
- What can go wrong at each step Business Idea Waterfall planning too much inventory Lean JIT Env (250 day story) Consistency SE, SD, automation, cloud Testing stage Cycle time repeatability branch time Approval times (approval time story) Prod deploy time and effort (launch calls story) Monitoring New issues (IE8 short story)
- Where to start
- All about change management and personal ownership Smaller for simplicity Stuff that matters Loosely coupled Tightly coupled
- 40 Mins DevOps more important with more people Teams of 10 people diff from teams 100s Common view more important Start with biggest issues to create + momentum Design DP to help minimize triage waste Build Freq, BAT, SV
- Break it down into stable subsystems Then build it up releasable
- Need to start build up you subsystem deployment pipelines with gates and stage Stages localize feedback (triage) Gates for cultural changes and block instability
- Define the system DP Complex system have more stages for localizing triage and gating instabilities Multiple stages have more opportunities for waste with repetitive tasks
- Define the system DP Complex system have more stages for localizing triage and gating instabilities Multiple stages have more opportunities for waste with repetitive tasks
- Minimizes rework with fast feedback and enables efficient triage Focus on long legs
- Separate new work issues from repetitive Issues with repetitive tasks and cycle time for repetitive work will be used to prioritize automation Start with Env and Test before CI
- Possible Results Complex Benefits are more pronounced 10s versus 100s Jez and David DP Engaged executives
Anúncio