Fundamentals of Deploy and Release


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Fundamentals of Deploy and Release

  1. 1. Fundamentals of Deploy and Release June 19th, 2014 Eric Minick DevOps Evangelist with IBM @EricMinick
  2. 2. Who’s that guy? Eric Minick DevOps Evangelist  Background as a developer, tester and tools guy with UrbanCode  Co-author of Application Release & Deploy for Dummies
  3. 3. 3 CEOs identify technology as the most important external force impacting their organizations – again Source: IBM Institute for Business Value, The Global CEO Study 2013. Question: “What are the most important external forces that will impact your organization over the next 3 to 5 years?” 2004 2006 2008 2010 2012 2013 1 2 3 6 4 5 7 8 9 1 2 3 6 4 5 7 8 9 1 2 3 6 4 5 7 8 9 1 2 3 6 4 5 7 8 9 1 2 3 6 4 5 7 8 9 Technology Factors Market Factors Macro-economic Factors People Skills Regulatory Concerns Socio-economic Factors Globalization Environmental Issues Geopolitical Factors 2 3 6 4 5 7 8 9 1 CEO Studies 2004–2013 External forces that will impact the organization
  4. 4. Software delivery Intelligent/ Connected Systems Software component in smart products driving increased value and differentiation Big Data Insights on new products by more efficiently interpreting massive quantities of data Cloud Demand for apps requires fast, scalable environments for dev and test, as well as production Instrumented Products Industry requirements demand faster response to regulations and standards, with traceability and quality Social Business Broader set of stakeholders collaborates to deliver continuous innovation and value Mobile Modern workforce expects constantly updated software to connect to enterprise systems Software delivery is at the heart of today’s top technology trends
  5. 5. To Win: Release More to Learn Faster
  6. 6. Delayed learning is why waterfall fails Idea Requirements Development Integrated Test Release Weeks / months to validate code matches Reqs Months or years to learn if ideas / requirements match the market need
  7. 7. Time to customer feedback is governed by risk Traditionally • Organizations looked to find a balance between speed, cost & risk. • Development teams were not as agile as they are today; testing never seemed to have enough time.
  8. 8. Time to customer feedback is governed by risk Traditionally • Organizations looked to find a balance between speed, cost & risk. • Development teams were not as agile as they are today; testing never seemed to have enough time. *Survey of 250 Testers 90% of testers have some but not “complete” confidence in the software that’s released. 4 testers are seeing faster releases per 1 that sees slower 34% of those who expressed no change were regularly releasing quarterly or better.
  9. 9. Shift Left: To win in the market, learn faster • Organizations are asking teams to release higher quality software sooner. • Development teams are becoming more and more agile; testing still never seems to have enough time.
  10. 10. How do we go faster? 10 Agile?
  11. 11. … but Agile didn’t help with Ops
  12. 12. DevOps: Unclogging Delivery Barriers to Faster Delivery Running Integration Tests Getting Test Environments Perceived Risk of Release Image credit: NOMAD
  13. 13. Automating Deploy and Release Automatically provision environments Quickly deliver changes to test Reduce risk when releasing
  14. 14. Core needs for Automation Build Dev Test System Test UAT Staging Prod 1. A button to press 2. Storage of Builds 4. Environment Definitions ♫ 5. Audit, Controls, & Governance 3. Defined Process
  15. 15. Automated process Fast, consistent and repeatable
  16. 16. Environment definitions Per-environment configuration and passwords
  17. 17. Artifact repository Know what you’re getting Where do the bits you deploy come from?
  18. 18. Access control What we need  Role-based access control  Access control by environment  Single source of access control  LDAP / Active Directory authentication (or authorization) Who can deploy to which environment
  19. 19. Audit trail What we need  Win at Clue: –Who –What –Where –When / How –Require no additional work  End-to-end traceability Know what happened
  20. 20. Automate because people aren’t machines Automated deployments leverage the strengths of people and machines. Alistair Cockburn, “Characterizing People as Non-Linear, First-Order Components in Software Development” Creative Consistent
  21. 21. Composite applications are hard because they have lots of pieces Image from
  22. 22. Makes our pipeline more complicated Build Dev Test System Test UAT Staging Prod
  23. 23. Multi-Application releases multiply complexity Versions Single App Multi App Applications 1 25 25010 Environments 2505 Teams 251 Changes 250050
  24. 24. Managing the orchestration
  25. 25. Transitions of a Snapshot Snapshot Snapshots / Release Versions Transitions of Components Dev ProdQA ? ? Snapshot Snapshot QADev Prod
  26. 26. Views into the pipeline must be broad
  27. 27. 27  Track your changes and dependencies in the context of a release  Detect what application is at risk Risk Management – Impact Analysis
  28. 28. Faster yet: tests & auto-promote
  29. 29. Run tests at the end of deployments Deploy Invoke Tests Promote Image credit: content/uploads/2011/05/smoking-server.jpg Rollback
  30. 30. Auto-progress what works / is approved DEV CERT QA PT PROD Phase DEV Phase SIT Phase QA Recurring Rules DEV CERT QA PT Phase DEV Phase QA DEV CERT QA PT Phase DEV Phase QA DEV SIT QA Staging Ready SIT Ready QA Ready Staging Phase DEV Phase QA Phase Staging • Recurring scheduled deployments • Fully automated deployments • Quality status enforced by the gates
  31. 31. Treat infrastructure the same
  32. 32. DevOps manages risk differently  The adoption of DevOps => increased velocity of application delivery  Puts pressure on the infrastructure to respond more quickly  Software Defined Environments enable you to capture infrastructure as a software artifact Application Changes Infrastructure Changes
  33. 33. Full stack engineering. Change is Change Application Changes Infrastructure Changes Consistent Incremental Change … …
  34. 34. In Summary  Software delivery is important  Automating and managing change helps: –Speed delivery –Improve quality  Coordinate change across complex systems –Don’t forget the infrastructure
  35. 35. We have tools
  36. 36. Push Button Deployments Role based security & gates Scalable Architecture 1.2.3 System of Record Everything is versioned & auditable Easy to use process designer Re-useable / Extensible Integrations & Workflows Continuous Delivery Across Environments IBM UrbanCode Deploy: App Deploy Automation
  37. 37. UCD with Patterns: Environments on Demand
  38. 38. IBM UrbanCode Release: Release Management and Coordination
  39. 39. Q&A @EricMinick Get the slides: More IBM UrbanCode stuff: