What is DevOps? How can it impact my Customers and my Business
•Download as PPTX, PDF•
1 like•1,059 views
QualiTest and Kubisys help clarify and explain what DevOps can do for you and your business. Experts will shed light on the purpose, the target, the goal and how DevOps can improve your testing process. For more information visit: www.QualiTestGroup.com
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
Similar to What is DevOps? How can it impact my Customers and my Business
Similar to What is DevOps? How can it impact my Customers and my Business (20)
More from Qualitest
More from Qualitest (20)
Recently uploaded
Recently uploaded (20)
What is DevOps? How can it impact my Customers and my Business
- 1. What is DevOps? How can it impact my Customers and my Business? community. competency. advocacy.1
- 2. Soumen leads Kubisys’ Alliances and Channel team. He has nearly 20 of years of experience with disruptive and transformational technologies from Virtualization to Cloud and Big Data. He brings a strategic and data driven approach to enable customers achieve their business agility objectives through the adoption of Kubisys’ industry leading solution in DevOps. Yaron is the CEO of Qualitest USA. He is an expert in load and performance testing and the implementation of automated testing tools. He has lead large-scale testing projects in the healthcare, medical devices, and utilities industries, as well as testing ERP, CRM and billing systems. He holds a BA in Business Administration and IT from the IDC, Israel and an MBA from the Executive Program at the Hebrew University, Israel.
- 3. Agenda • DevOps Mindset – Brief Review • Enabling DevOps through better Testing and Automation • Accelerating and De-Risking Deployments • Revenue and Margin Impact
- 4. Accelerating and De-Risking Deployments community. competency. advocacy.4 How can it impact my Customers and my Business?
- 5. Why DevOps with Dynamics? Excerpts from 2013 MIT Sloan Management Study on Software Development Lifecycle For every 25% increase in complexity to be automated, the complexity of the software increases by 100% * The cost of fixing an error in production can be 100 times as high as during development… * Software specialists spend 40-50% of their time on avoidable reworks… Panorama Consulting 2011 ERP Report 61.1% of ERP implementations take longer than expected 74.1% of ERP projects exceed budget 40% of ERP implementations cause major operational disruption after “go live” 85% of ERP implementations involve software customization
- 6. 6 WHAT IS DEVOPS? » Who: Developers, QA and Operations » What (Goal): Clarity, Consistency and Collaboration to understand the changes that each release brings to the IT and customer environments » Why: Increase business benefits by reducing the transaction cost associated with delivering incremental change. » How: Methodology and tools that continue to evolve
- 7. 7 A NEW APPROACH TO DEVOPS PEOPLE PROCESS TOOLS • Visibility • Self-Service • Governance • On-Demand • Change Mgt • Better Testing • Automation • Up-to-Date • Non-intrusive
- 8. DevOps – What are we trying to achieve? Production ? Infrastructure Rqm’nts ? Governance Policies ? Application Security ? Expected Changes ? New Integrations ? Performance Impact Development UAT/ProdQA Accelerate Deployment Minimize Risk
- 9. Shift Left for Greater Agility with Real Automation • Shifting Operations left for environment access, availability, and quality • Virtualization and Cloud are enablers, but don’t address the transition lag • Configuration Drift -- Existing processes still reliant on stale templates resulting in drift • Garbage in Garbage Out -- Existing tools simply automate stale template deployment • Automation should be less API reliant to automate tasks that aren’t needed 9
- 10. The Traditional “Solution” = 4 to 6 changes per year PROD Today Original App Prod Please provision a new Dev environment Change IP, Hostname and URL Please provision a new QA environment Change IP, Hostname and URL IT Ops Queue Dev QA Ready for Production Ready for Testing IT Ops Queue 1-3 Weeks 1-3 Weeks
- 11. Making DevOps Deliver • Remove Dependency on Manual Template Creation and Synchronization • Service Catalog • Self-Service • Environments on Demand • Automated Testing • Agile Development Principles
- 12. From 28 Days to 1 Day = 20+ Changes per year PRODProd Let me provision my own Dev environment Same IP, Hostname & URL Dev QA R e On Demand Environments and Catalog ReviewEnvironment/ ServiceCatalog Time to test the new build. Let me provision my own QA environment Same IP, Hostname & URL ReviewEnvironment/ ServiceCatalog R e Production App Less than 1 Day Less than 1 Day
- 13. CHANGING THE GAME Time to reproduce production environment reduced from 1 week to < 1 hr Developer productivity increased > 50% (reduced re-work and wait times) Reduced time to resolution and deployment by 85% Customer Results Leveraging “Disruption”… • Maximize profits on fixed cost and performance based contracts • Expand the reach & availability of your high end knowledge workers 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Current Kubisys Margin Operation Deployment Development Design Analysis Diagnostic MSFT Sure Step On-Demand Env’t
- 14. Quality Assurance in DevOps community. competency. advocacy.14
- 15. Where does QA fit in DevOps? • Addressing a misconception • QA is not a bottleneck • DevOps is about closing the distance between development and operations through: • Meaningful collaboration • Early engagement • Continuous processes 15
- 16. Shift Left Principle • Engage QA early • Push tests to lower levels • Test continuously • Benefits: • Fewer defects created • Defects discovered earlier • Cost per defect drastically reduced 16
- 17. Shift Left Impediments • Shifting Operations left for environment access, availability, and quality • Do we have the capacity? • How long does it take? • Who will establish it? • Granting Ops capabilities to QA • Designing for test • TDD, BDD, and more 17
- 18. Positioning QA with Development and Operations • Development • Engage as early as possible in the life cycle • Generate test automation at lower levels within the product • Reduce the overall demand for manual testing and testing at the GUI level 18 • Operations • Testing and Monitoring in all environments • Environments should be as production-like as possible • QA needs more control and access to environments • Continuous feedback and communication • Testing of Operations processes
- 19. The Evolution of the Modern Tester • Traditional Tester Skills • Analytical and Logical Thinking • Intellectual Curiosity • Critical Thinking and Rational Deduction • Ability to Identify and Apply Fundamental Knowledge 19 • Modern Tester Skills • Reading and Writing Code • Grasping the Bigger Picture • Ability to Recognize and Address Design Challenges • Ability to Communicate on both Technical and Business Needs • Ability to identify appropriate use cases for manual testing (exploratory testing for learning and test design for example)
- 20. Test Automation in a DevOps World • Occurs at every level and type of testing • Strongly focused on early stages of the SDLC and lower levels of functionality • No automation without CI/CD integration • Enabling regular and frequent releases 20
- 21. Test Automation and Time to Market • DevOps is largely about improving time to market • Test Automation is no longer a nice to have • No longer justify test automation with ROI • Now viewed as one piece of the overall DevOps approach • Key metric is always time to market 21
- 22. Critical Test Automation Tool Features • CI/CD Integration • Effective logging and reporting • Ability to span SDLC • Easily described in relevant business language (either through domain language or robust documentation)
- 23. Integrating Testing into your SDLC • Automated testing allows for a full cycle of feedback at every stage of the SDLC • Each deployment becomes a miniature release cycle in its own right. • At every stage we never stop producing feed back from both testing and monitoring
- 24. What MUST you take away from this session… DevOps leveraging On-Demand Environments is the Industry direction Adapting new technologies like On-Demand Environments with Test Automation will enable your organization to MAXIMIZE REVENUE Don’t fall into the trap of Reducing Scope to win deals Thought leadership in this exploding area strengthens your “trusted advisor” position with clients Leveraging the disruptive potential of On-Demand Production Accurate Environments creates the opportunity for new service offerings, additional revenue streams and more resilient client relationships Change the Game in Service Delivery by delivering projects on time on budget with greater Margin
- 25. FOLLOW UP Multi-App Integration Hybrid Cloud Integration BPM Recovery Plans ISV Integration Post Sales Managed Service Rapid Upgrades For Follow Up Discussions contact Kubisys and Qualitest Group Dynamics Communities • Joe Carroll joe.carroll@dynamiccommunities.com www.kubisys.com Soumen Chowdhury (NJ) chowdhury@kubisys.com EJ Harof (GA) harof@kubisys.com www.qualitestgroup.com Yaron Kottler (CT) yaronk@qualitestgroup.com Amanda Johnson (CT) amadaj@qualitestgroup.com
Editor's Notes
- AX7 and LCS is trying to address this problem. But there are limitations – only for 2012 R2, still delivering templatized environments on Azure not customized and only a handful of products take advantage of this AX7 and LCS are focused on net new customers There are complementary products that allow you to address your existing customer’s legacy deployments and upgrades You can achieve on premise on demand environments to deliver this capability that goes beyond the limitations of spinning up VMs
- Industry insight into environment access, availability, and quality Talk about the three questions and additional concerns Release cycle / turnaround time to QA, esp related to environments Designing for test
- Engage with client: Ask if this process is familiar, if not ask to specify their internal process Ask about the timeframe, is it accurate? Roles, who is involved? Wearing more than one hat a time?
- What is the impact of this savings to you? How can your team have more control and clarity during the engagement Dependence on customer (Down) Incomplete Information (Dependencies)(Down) Root Cause Analysis Time (Down) Unproductive Fingerpointing that generates no revenue and hurts your credibility Increase Time to Value – instead of reducing scope to deliver a more cost effective bid – deliver more in less time safely to win the bid! Improve Testing
- A common misconception in the past has been to view QA as a bottleneck between dev and ops. This was never truly in line with reality and DevOps makes it even less so. QA is and should be talked about as an enabler of DevOps and faster time to market. What DevOps is really about is a combination of meaningful collaboration and early engagement supported by continuous processes linking all facets of software development and maintenance.
- With the primary high level goal of DevOps being to shorten the gap between dev and ops, we arrive at the Shift Left Principle. The idea is to engage everything that would traditionally have resided downstream from development at much earlier stages in the SDLC. This obviously includes testing. QA needs to be engaged far earlier in the process, preferably long before development actually starts. Tests need to be pushed to lower levels within the product with a strong emphasis on unit and API level testing. And testing needs to be performed continuously, at every stage of the lifecycle. With an early engagement model to product creation, projects will create fewer defects, find defects earlier, and drastically reduce the overall cost of defects in general.
- Industry insight into environment access, availability, and quality Talk about the three questions and additional concerns Release cycle / turnaround time to QA, esp related to environments Designing for test
- Under DevOps, QA needs to have a strong and close relationship with both Development and Operations. So what is involved in establishing and operating this collaboration? On the Development side it is imperative to engage as early in the SDLC as possible. Even testing as low as Unit Testing can no longer be owned entirely by Development. The focus of QA needs to be brought down to these lower levels of testing with much more emphasis than has been true in the past. The result should be a reduction in the overall demand for manual testing and testing at the GUI level, which is great because higher level tests inherently have higher maintenance and execution costs. When it comes to Operations, testing an monitoring needs to be happening in all environments. If Operations is engaged late in the process, developing monitoring capability for production environments and linking the feedback to QA processes can lag behind the speed at which product is delivered. This means that pre production environments need to be as production like as possible. To ensure accurate and complete monitoring, this additionally requires that the environments be more accessible to QA, both from the perspective of existing environments and the creation of additional environments. While in this sense, Operations supports QA, QA also needs to support Operations in strategizing its monitoring capability to appropriate report on meaningful product features and availability.
- With the integration and overlap of dev and ops roles with QA, the modern tester has evolved. Today's tester still needs to be everything he or she was in the past, but there is more stress now on tester's having enough of the developer skill set to be engaged early in the product lifecycle. Testers should not only be aware of unit testing activities, but be capable of understanding, writing, maintaining, and executing them. By engaging the tester at ground level we take the first step towards enabling a healthy and continuous QA process all the way to release and beyond. QA should also be heavily engaged in the process of monitoring and feedback that happens after deployments. Collaboration between QA and Ops enables faster and more seamless turnaround for defects and feedback received post-deployment to any environment.
- When we talk about early engagement and continuous processes, this means a lot to the world of test automation. While many developers, when asked, would proclaim nearly 100% unit test coverage without the involvement of QA, this is not a fact of the real world. While there is no concrete answer to how much coverage is needed and at what levels, the right types of testing need to be performed at the right stages, and this only becomes feasible through automation. Generally speaking, testing of a particular feature or module should occur at the lowest truly testable level. Integration or API features tested at the GUI level, for example, are not necessarily getting their fair share of coverage and will generally be more expensive to execute and maintain at any rate. That being said, no automation tool is going to survive without strong CI/CD tool integration. Automated testing is happening at every level and far too frequently to not be an automated process. This is the most strict requirement of test automation in DevOps. Without this, test automation can not do its job of properly enabling continuous and frequent release.
- With the position that test automation holds in DevOps, there are certain features of test automation that are absolutely necessitated. As mentioned, strong integration with your continuous integration or delivery platform is an absolute must. Beyond that, without effective logging and reporting test automation in general loses much of its usefulness. Since DevOps takes much of the human interaction out of this process, the need here is further exaggerated. Additionally, with testing happening at all stages of the SDLC, an automation tool (or suite of tools) that can’t facilitate this will not properly serve the needs of your organization. Finally, for test automation to be truly useful, we need to be able to tie it to the actual coverage or benefit that it carries. With collaboration across previously distinct groups of people, talking about test coverage, results, and ramifications in language that is meaningful to all parties is something that needs to be addressed. This can be accomplished through the use of domain language and/or robust formal documentation. Strict standards need to be created and enforced through a combination of technology and process in order for this to be the case.
- We’ve discussed the need to test across the lifecycle, but how do we actually do this? The general answer is basically that any time code “moves” it needs to be tested. When a developer commits code, unit tests execute. This committed code has now merged with the rest of the component team and this merge is tested. The product here is then integrated into a larger trunk which should trigger our integration tests, and so on. This pattern repeats ad nauseum all the way to production in a production-like environment at every step along the way. Luckily, with much of this process automated, we’re not suffering the cyclical tedium you might expect. Rather, it becomes business as usual and is absolutely ingrained in everything that we do while creating a product. This produces a constantly churning cycle of progress, communication, and feedback that is rapidly retooled into more progress.