Your SlideShare is downloading. ×
  • Like
  • Save
Agile Development: How to Release Apps at the Speed of Business
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Agile Development: How to Release Apps at the Speed of Business

  • 383 views
Published

Many companies plan for changes and improvements in software releases several times a year. McKesson Health Solutions’ Clear Coverage™ business model requires their IT team to respond to hundreds of …

Many companies plan for changes and improvements in software releases several times a year. McKesson Health Solutions’ Clear Coverage™ business model requires their IT team to respond to hundreds of releases every year – which they do efficiently and effectively – every day, every quarter.

Join featured speakers Michelle Grover, Manager of Agile Development, McKesson Health Solutions, and Joe Hoffman, Director Sales Engineering, Western Region, Compuware APM, to learn how McKesson Health Solutions does it – and how your IT team, too, can release apps at the speed of your business!

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
383
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Title Slide - Lifecycle
  • It’s not an academic theory, it is successfully practiced daily by many companies.

    Why is it used? It works. Lets consider the typical war room scenario…
  • They’ve dropped the ties, but not much else has changed.
  • An old but still very true principle: Cost of bug fixing is exponential to release cycle stage.

  • CAMS is taken from OpsCode (Creators of Chef) Blog: http://www.opscode.com/blog/2010/07/16/what-devops-means-to-me/
    Culture People and process first.  If you don’t have culture, all automation attempts will be fruitless.
    Automation This is one of the places you start once you understand your culture.  At this point, the tools can start to stitch together an automation fabric for Devops.  Tools for release management, provisioning, configuration management, systems integration, monitoring and control, and orchestration become important pieces in building a Devops fabric.
    Measurement If you can’t measure, you can’t improve.  A successful Devops implementation will measure everything it can as often as it can… performance metrics, process metrics, and even people metrics.
    Sharing Sharing is the loopback in the CAMS cycle.  Creating a culture where people share ideas and problems is critical.  Jody Mulkey, the CIO at Shopzilla, told me that they get in the war room the developers and operations teams describe the problem as the enemy, not each other.  Another interesting motivation in the Devops movement is the way sharing Devops success stories helps others.   First, it attracts talent, and second, there is a belief that by exposing ideas you can create a great open feedback that in the end helps them improve


    The change that is required is already well understood in the DevOps movement that’s been going on for years – BUT – it is important to add Performance as Key Requirement to Culture, Automation, Measurement and Sharing.
    Culture: PERFORMANCE is a key requirement for everything that is done throughout the delivery chain. We have heard that a lot of the problems that lead to a War Room scenario are problems that could be found earlier if there would be a focus on Performance and Quality throughout the organization
    Automation: Automation is Key for DevOps and Agile Development. What needs to change is that performance and architectural problems are automatically detected in the development and delivery process. This can be achieved by focusing automated testing for exactly these problems – whether it is in C/I or in the “traditional” test area
    Measurement: We can only measure success if we have Key Performance Indicators for each team, e.g: Test Coverage %, Number of Tests Executed, Throughput, Response Time, Number of Deployments, … - an additional focus must be on measures that allow us to track performance and architectural issues. This allows us to identify and prevent any performance regressions as soon as they get introduced
    Sharing:
  • By Gene Kim.
    Not just for nerds, highly recommended for everyone in the company (Cxx, Business Office, Operations, etc)
  • Via mobile marketplace, instant feedback from users on THEIR PERCEPTION of your app. How many stars?

    Risk Reduction: Giving the business the confidence to compete and Lead in the market.
  • Divider Slide - Mobile
  • Social links

Transcript

  • 1. 11 Michelle Grover, Manager of Agile Development, McKesson Joe Hoffman, Director Sales Engineering, Western Region, Compuware APM Agile Development: How to Release Apps at the Speed of Business
  • 2. About McKesson  Large Fortune-15 Company  About 180 years old  > 40,000 employees worldwide  MTS – McKesson Technology Solutions  MHS – McKesson Health Solutions  DM – Decision Management McKesson MTS MHS DM
  • 3. About Our Product: Clear Coverage™  Software-as-a-Service Public Internet application  Used as a “Prior Auth” solution, to enhance and automate Authorization Requests between Providers and Payers  Customers are Payer entities  Insurance companies  State Medicaid/Medicare Managers  Users are Provider and Payer administrative staff Technology Stack:  Adobe Flex / Flash  Java REST and AMF services running in Tomcat, using Spring for DI  Oracle DB, using Hibernate for ORM
  • 4. Our Continuous Delivery Model  Every two weeks:  We deploy the latest code branch to a customer-facing, public-internet, testing system  Every four weeks:  We promote the latest customer-facing branch to the production system  As we develop, we deploy the latest code changes to an internal test system  As needed, we patch Emergency code changes and redeploy to the customer- facing systems
  • 5. Troubleshooting a Problem We were experiencing production slow downs. Our process was to enlist our Production Ops Team to help us figure out the Root Cause of our slowdown. The tools they used could tell us simple things like when the GC and Memory Thresholds were over a certain percentage. But, trying to figure out what was actually causing the performance issue was something these tools were not designed to do.
  • 6. Right Tool for the Job(s)  dynaTrace® helped us identify several slow running queries  Using session snapshots we were able to pinpoint the time of day when this issue most often surfaced  We walked through the snapshots with Ops and we added additional Servers and Cores to provide additional horsepower to our application
  • 7. Ops and Development  dynaTrace Training for Members of the Ops Team  Working closely with Ops to find issues prior to emergency status  Working with Ops to speak the same language regarding Production Issues
  • 8. Long Term Goals dynaTrace and Clear Coverage™ Moving towards a Continuous Deployment Model from our Continuous Delivery Model  Using dynaTrace to provide a session snapshot prior to each deployment  Comparing the sessions to validate the state of the system prior to and after deployment
  • 9. 12 Who is Doing It? How Many Successful Deployments Can They Do? 300 Deployments / Year 50-60 Deployments / Day 10+ Deployments / Day Every 11.6 seconds
  • 10. The “War Room” – back then . . . 'Houston, we have a problem‘ NASA Mission Control Center, Apollo 13, 1970
  • 11. The “War Room” – NOW Facebook December 2012
  • 12. 15 Status Quo: Bugfixing in Production Happens But! ~80% of problems caused by ~20% patterns YES we know this • 80% Dev Time in Bug Fixing • $60B Defect Costs
  • 13. 16 Root Cause: Missing Collaboration Shopzilla CIO (in 2010): “… when they get in the war room - the developers and ops teams describe the problem as the enemy, not each other” Image taken from https://www.scriptrock.com/blog/devops-whats-hype-about/
  • 14. 17 Root Cause: Disconnected Teams
  • 15. 18 Solution? DevOps + Performance Focus
  • 16. 19 If we do all that . . .
  • 17. 20 We align Technical Goals … 80% Dev Time for Bug Fixing $60B Costs by Defects
  • 18. 21 … with Business Goals
  • 19. 22 Continuous Performance in Test Automation Build 17 testPurchase OK testSearch OK Build 18 testPurchase FAILED testSearch OK Build # Test Case Status Test Framework Results We identified a regression
  • 20. 23 Continuous Performance in Test Automation Build 17 testPurchase OK testSearch OK Build 18 testPurchase FAILED testSearch OK Build 19 testPurchase OK testSearch OK Build # Test Case Status Test Framework Results Problem solved
  • 21. 24 Continuous Performance in Test Automation Build 20 testPurchase OK testSearch OK Build 17 testPurchase OK testSearch OK Build 18 testPurchase FAILED testSearch OK Build 19 testPurchase OK testSearch OK Build # Test Case Status # SQL # Excep CPU Test Framework Results Architectural Data Lets look behind the scenes
  • 22. 25 Continuous Performance in Test Automation Build 20 testPurchase OK testSearch OK Build 17 testPurchase OK testSearch OK Build 18 testPurchase FAILED testSearch OK Build 19 testPurchase OK testSearch OK Build # Test Case Status # SQL # Excep CPU 12 0 120ms 3 1 68ms 12 5 60ms 3 1 68ms Test Framework Results Architectural Data Lets look behind the scenes Exceptions probably reason for failed tests
  • 23. 26 Continuous Performance in Test Automation 12 0 120ms 3 1 68ms Build 20 testPurchase OK testSearch OK Build 17 testPurchase OK testSearch OK Build 18 testPurchase FAILED testSearch OK Build 19 testPurchase OK testSearch OK Build # Test Case Status # SQL # Excep CPU 12 0 120ms 3 1 68ms 12 5 60ms 3 1 68ms 75 0 230ms 3 1 68ms Test Framework Results Architectural Data Problem fixed but now we have an architectural regression Problem fixed but now we have an architectural regression
  • 24. 27 Continuous Performance in Test Automation 12 0 120ms 3 1 68ms Build 20 testPurchase OK testSearch OK Build 17 testPurchase OK testSearch OK Build 18 testPurchase FAILED testSearch OK Build 19 testPurchase OK testSearch OK Build # Test Case Status # SQL # Excep CPU 12 0 120ms 3 1 68ms 12 5 60ms 3 1 68ms 75 0 230ms 3 1 68ms Test Framework Results Architectural Data Now we have the functional and architectural confidence
  • 25. 28 Test Automation – Automatically detect change Measure History When did we introduce that regression? Test Category Unit, Performance, UI-driven, Load Test Test Platform OS, Browser Test Status Current and Previous based on analyzed measures Measure Violations? Which measures indicate a regression? Expected Value Range Auto-Learn: Which value range is expected for this measure? Expected Value Range Auto-Learn: Which value range is expected for this measure?
  • 26. 29 Automate Reports Embed your Architectural Results in Jenkins
  • 27. What’s the next step?
  • 28. 31 Recommended Book https://itrevolution.wufoo.com/forms/phoenix-project-ebook-offer/ • Systems Thinking • Amplify Feedback loop • Culture of Continual Experimentation and Learning
  • 29. 32 Want MORE of these and more details? http://apmblog.compuware.com
  • 30. 33 What’s the Goal? • Produce the best product that solves a critical Business Problem for my Customers • Make releasing software a low-risk, frequent, cheap, fast, and predictable process • How? DevOps!
  • 31. 34 Attributes of a Successful Implementation •Automation – Repeatability – Measurable – quickness •Communication – Removal of barriers – Work like a single team – Celebrate your wins •Buy-in on the 7th Floor •Willing to take risk – Try it; you’ll like it
  • 32. 35 Pitfalls, Roadblocks, Pot Holes to DevOps • Not a replacement for a solid business • Product, Marketing, Leadership, etc • Business Goals -> Technical actions • Don’t do it because it’s Cool. • Do it like your business depends on it. – It DOES! • Executive Sponsorship • If you don’t have it -> Do not pass GO! • Cultural Shift – Is your company ready? • Threats • Rigid Organization • Silo Mentality of departments and teams • Large enterprises • Protective Job behavior
  • 33. 36 What’s this got to do with APM? • As you automate, how to handle the deluge of data? Further automation. • How to quickly respond to negative market feedback? AppStore rating? • Business Confidence to release faster • Risk Reduction
  • 34. 37 How to get there?
  • 35. 38 Questions, Comments, Sharing Join the conversation now! Tweet your questions using #APMLive!
  • 36. 39 www.compuware.com/APM Learn More About Compuware APM Participate in Compuware APM Discussion Forums apmcommunity.compuware.com Join our LinkedIn group Compuware APM User Group Follow us on Twitter www.twitter.com/CompuwareAPM Read our Blog About:Performance Like us on Facebook www.facebook.com/CompuwareAPM Watch our Videos & product Demos www.youtube.com/Compuware COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE
  • 37. 40 © 2011 Compuware Corporation — All Rights Reserved© 2011 Compuware Corporation — All Rights Reserved 40 COMPANY CONFIDENTIAL – DO NOT DISTRIBUTE