DevOps Summit 2014 Delivering your Applications without a Hitch using Automated Change Validation
Download as PPTX, PDF0 likes194 views
The document outlines assumptions about developers being incentivized to move software into production while navigating validation and progress through different environments. It emphasizes the importance of understanding potential problems through concepts like Bayes rule and suggests practical solutions such as creating adjustable interfaces and incentivizing thorough testing. Ultimately, the goal is to deliver business value effectively.
DevOps Summit 2014 Delivering your Applications without a Hitch using Automated Change Validation
- 1. Ian Kelly - @IanAKelly
- 2. My assumptions about you • Incented to get software into production
- 3. My assumptions about you • Incented to get software into production • Progress Software through environments based upon validation
- 4. My assumptions about you • Incented to get software into production • Progress Software through environments based upon validation • Have a mental model of what might be acceptable and what might be a bad sign
- 5. The Problem • Ourselves – Software – Our Budgets – Our Boss – El Niño
- 8. View of validation is… • Clean
- 10. View of validation is… • Clean • Defined
- 12. View of validation is… • Clean • Defined • Manicured
- 14. Focus • Each environment has a different focus and field of view
- 16. Θ is the Problem • Bayes Rule
- 18. Θ is the Problem • Bayes Rule • Nondeterministic
- 20. Θ is the Problem • Bayes Rule • Nondeterministic • Deviation
- 22. We took the wrong pill
- 25. So what can we do? • Start with Everything
- 27. Create dials • Make your interfaced adjustable
- 30. Closing it out • Put Production facsimiles into the hands of your developers
- 31. Closing it out • Put Production facsimiles into the hands of your developers • Add the maintenance of these interfaces to your deployment process
- 32. Closing it out • Put Production facsimiles into the hands of your developers • Add the maintenance of these interfaces to your deployment process • Understand your Θ
- 33. Closing it out • Put Production facsimiles into the hands of your developers • Add the maintenance of these interfaces to your deployment process • Understand your Θ • Incentivize boundary and extents testing
- 34. Closing it out • Put Production facsimiles into the hands of your developers • Add the maintenance of these interfaces to your deployment process • Understand your Θ • Incentivize boundary and extents testing • Deliver business value for your function
- 35. Ian Kelly - @IanAKelly
Editor's Notes
- #3: You have the goal or desire to deliver running software – that thing called business value. This may be a no brainer for you but seriously this may not be your role at your organization – some of you are human roadblocks, hired to mire, slow, and generally disrupt (also called control) releases.
- #4: You have lower environments and originally the goal was to make them as close to reality as possible. This was never the goal of the folks who mandated this practice and they never really gave you the tools but, there you are…
- #5: So if you have been somewhere long enough you learn these things – Oh that is always red, that never works because of XYZ in this environment If you do what you have always done, why do you complain when you get what you have always got… I am challenging you to make some new ventures into learning and exploring
- #9: We test the functionality as the requirements state – we follow the flows to the letter, and we do it in environments that are so unique they may be termed antiseptic
- #10: We treat QA or Maybe UAT environments like this clean room – nothing is added that is not first sanitized. So what does that mean? Our environments are sparse! Very Sparse!
- #28: Bend them to your will
- #29: Make them respond faster, slower, with the wrong data, with the right errors, with dirty state, with partial replied, with corrupt replies – With a 200 and no content, with a 404 and the right resource
- #30: Interesting things occur when you can validate in these virtualized systems