Test automation *is not* a pre-requisite for Continuous Delivery
An interesting talk from Sally Goble (The Guardian Head Of Quality) from Porto Tech Hub Conference 2016)
https://www.youtube.com/watch?v=852OVo6HzcI (VIDEO REMOVED)
Recording from DevOpsDays London 2017
https://www.youtube.com/watch?v=RY1dLbfm5_Y
My notes:
Minute 3:00
"Test automation is not a pre-requisite for Continuous Delivery"
<ad> For a definition of "Continuous Delivery" look here
http://gfader.tumblr.com/post/78335987657/do-you-know-the-difference-between-continuous
</ad>
Minute 6:15
What they had before:
* code freezes, go/no-go meetings, release managers, huge process, huge problems with delivery of software, massive regression testing suite
Major issues:
* #1 no deploy without downtime
* #2 no rollback mechanism
* #3 manual deploy process
Motto:
"Not long wrong"
I think this is focusing on MTTR (mean time to repair). Similar strategy at Facebook: "Real Men only Roll Forward" http://gfader.tumblr.com/post/75704235866/real-men-only-roll-forward-quote
Can everybody use this approach?
Maybe not
* Self-driving cars?
* Health or Safety critical environment?
How to mitigate risk?
* Single Feature Releases (including traceability)
* Feature Toggles (Flags or Toggles called sometimes)
* Monitoring and Alerting
* Tests in low traffic areas (<-- high traffic area is covered by canary release)
* Canary releases
Minute 19:30
Benefits of this approach:
1. Faster delivery benefited customers and stakeholders
2. Teams cared more when responsibilities were shared
3. Started adding value in unexpected ways -> testing != quality (Dashboards, TestAutomation,...)
Minute 29:30
Adapt and evolve!
Don't think that things that you were doing 2 years ago are appropriate doing now
Thoughts from myself after watching:
* The whole team (including client) needs to be aware of the strategy
* Are you empowered enough to fix issues immediately in Production? (Client relationship?)
* Do you have enough traffic to run Canary Releases?
