Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Quality over Continuous Delivery
Similar to Quality over Continuous Delivery (20)
Recently uploaded
Recently uploaded (20)
Quality over Continuous Delivery
- 1. Quality > Continuous Delivery From concept to market, Damn fast, Damn safe
- 2. • Automated Deploy Quality Driver • Continuous Integration Quality Gatekeeper • TDD Quality First Gate • Automated Acceptance Quality Second Gate Testing • DevOps Remove Quality Barriers • … … Where’d Continuous Delivery Go!?
- 3. Where’d Continuous Delivery Go!?
- 4. Simplicity + Quality = Speed
- 5. 1 - BUILT IN QUALITY
- 6. A bug introduced in development costs up to 10 times more to fix by the time it hits production McConnell, Steve (2004). Code Complete (2nd ed.). Microsoft Press Bugs In Production!?
- 7. • Miscommunicated requirements – Executable specifications • Lazy error handling – Fail fast, fail hard • Insufficient reporting of errors – NewRelic / Graylog2 / ELMAH • Misaligned test environments – Scripted environments • Too much code to manage – Componentization – Acceptance-test driven development Kill Bugs, Kill The Causes of Bugs
- 8. 2 - STABILITY & CONTINUOUS INTEGRATION
- 10. Build Pipelines
- 11. 3 - CONFIGURATION MANAGEMENT
- 12. The stuff we make is valuable all of it If we build it, we version control it Source code Use cases Integration tests Environments Database schema Documentation Continuous Integration External dependencies Version Control Everything
- 13. 4 - FEEDBACK CYCLES
- 14. WHAT DO WE DO?
- 15. What Do We Do?
Editor's Notes
- Morning Here I am in front of a Powerpoint slide Not my usual habitat, so you'll have to bear with me. Normally… CLICK Not today… CLICK Subject actually close to my heart Very disorganised person. Spectacular FTP failures, cooker hoods delivered to my house, etc. Personal vendetta. Deficiencies in my practice, makes up for Blog – 2 years, 30 articles. Some of most popular articles When the idea of SME came up…. When the thought of applying CD at DRL came up, the CD concept actually fell back a little for me. CLICK I want to talk more about this stuff. CLICK Let me explain why.
- So where'd CD go? When first started, expected to show this kinda stuff. Let’s quickly talk through this list. AD - magic btn, painlessly & quickly, code from integ - QA - live. CI - We've already got this thing, right? Moved CC, TC new big thing, doing good? TDD - Got this too. Ignore legacy, new code's = TDD IT - Not hot. We have it, isle of Selenium, Ruby, non-cohesive, not integral factory. DevOps - Most us dunno meaning - maybe it cross-functional teams? Challenges. Disconnected, Disparate may end play together, but how do we see value /now/? The thread through all of this, in my opinion, has to be quality. - Magic button – Carrot. X happns… click button But we can't, quality. Driver for me - CI, done right, is the gatekeeper. It's the thing telling you, "Nope... you no click the button". When CI = gospel, we click - First gate, Core = 15%, AOL = 11%, other between 0, DD svc = 80%. - ATDD, BDD. Learning for us – we do this up front. Tests that prove not tanked config file, user control declaration, page caching product info page isn't breaking live review data. 2nd quality gate/everything/ that a QA would test across more than one sprint. DevOps. Recent - AOL deploy issues. Magic button driving us forward, CI environment able to do, test environments able run automation, not on our own
- What about the cost of this? We can chase this thing down as voraciously as we like - standing here now I can't guarantee that the magic button is being pressed 3, 4 times a day is right for us. I can guarantee you all that the quality we'd have to bake into everything we do along this journey, I'll have all of that please.
- If we want to get ourselves off the blocks now, we want to start reaping the benefits now, we need to find that sweet spot between quality and simplicity. Let’s have a roadmap to take us 6 months, 12 months, 3 years down the line, but we’re doing a lot of this stuff now, our immediate problems is making quality a simple, obvious thing. Let’s have a roadmap for 6 months, 12 mons, 3 years down the line, but our immediate challenge is to make quality a simple, obvious thing.
- First of the four pillars of DRL Quality Delivery
- Optimistic number, IMHO. Why do we let bugs get this far? I hate BAU! On avg, 3 ppl in dev wrld along dedicated 2 of those people deliving TDD and similar automation would leave 3 rd person nowt to do.
- We aren’t hot at dealing with bugs, nor the causes of bugs. Crappy SD software Poor understanding of causes of bugs Lack of action to prevent reoccurences
- 2 nd pillar Robots doing all the stuff, while we do the brainy stuff.
- Nirvana of a continuous delivery process. Trustworthy data, that visualises and drives our end-to-end process.
- Svalbard Global Seed Vault Not an Ikea flatpack Opned 2008 Norway Half a million
- Not complicated Challenges in how we move from centralised to distributed Surmountable challenges
- Nature did this – it took billions of years A computer did this in a matter of months or even weeks Computer can mutate and evolve something like this 100s of 1000s of times a second Nature didn’t have that luxury. We need to be like this.
- What do we do I’ve mentioned a roadmap, my goal as a SME is to establish that, and here’s how
- Let’s start with what we know. We know feedback cycles, let’s use them. Every dev here by now knows the red, green, refactor loop. Around this, we need a much, much tigher acceptance test loop. And of course we need to automate this. We then throw around this our quality gatekeeper – our integration scripting tools We look for automations that we’re not yet doing – can we tighten up our deploy process, can we tighten up our regression pack? Stabilise – we can’t keep this cycle going forever, need time to port knowledge across, time to review where we are, etc.