Chasing the Rainbow

Getting to Continuous Delivery from a standing start

Transcript

1. Chasing the rainbow
2. Continuous Delivery from a standing start
3. About me! • Tech team lead at Dyson • Been working in IoT for 14 years • Passionate about lean agile software development now!
4. Our Continuous Delivery Journey Image from http://rupakshah.com/
5. Our Continuous Delivery Journey • Where we started • What we learnt • How we kept going • Where we were after 18 months
6. Where we were starting? image from https://neurosculptinginstitute.com/
7. Where we were starting? • Initial focus on proving proposition • Bringing development in house • Team split between sites • Business logic tightly coupled to CMS, communicating via the DB • Team new to building complex systems from scratch
8. So how bad was it?
9. I wouldn’t start from there! Image from https://onsizzle.com
10. I wouldn’t start from there! • Not able to build deployable • No CI Environment • No Tests • Restarting problematic • Technical Debt increasing • New Team
11. The only way is up! Image from https://www.tripadvisor.co.uk
12. The only way is up! • Releases late to minimize impact • Frequently had problems during releasing • Manual patching to bring up after upgrade • Development environments different to production
13. Where we needed to get to This image cannot currently be displayed. Image from http://www.mobiloitte.com/
14. Where we needed to get to • Releasing small changes rapidly • Releasing is painless and routine • Able to quickly test ideas • Release at cadence seen prior to launch
15. It’s not going to be easy! Image from http://uk.askmen.com/
16. What was working for us? • Excellent motivated Team • New tech lead with strong CD experience • PM who was new to CD • Trust from the business
17. Where to start?
18. What is causing the most friction? Image from https://youtu.be/EOV2byS8fOkimage
19. Build on something solid Image from http://cbeb.tk/
20. Build on something solid • Must build in house • Everything is triggered from it • Can be fragile but necessary • Something firm to build on
21. Getting the deployment automated Image from http://www.denofgeek.com/
22. Getting the deployment automated • Ugly is better than nothing • Gives the ability to improve • Things start to change quickly • 2 manual step are too many
23. It does look great over there! Image from https://flic.kr/p/PtcqS
24. Small Steps Image from http://grandmaspearls.org/
25. What's next?
26. Start to automate tests Image from https://youtu.be/c9LiX_7AyN4
27. Start to automate tests • Cannot release quicker without tests automated • The more features you add the more time it takes to test • Without, drives all the wrong behaviors • Helps stop the rot
28. Start with acceptance tests Image from http://www.mozbot.co.uk/
29. Start with acceptance tests • Ensures the system works for the customer • Ensures you are building the right thing • Can then safely add unit tests • Can form the basis for load tests
30. Even a handful helps Image from http://www.photl.com/
31. Even a handful helps • Get real value just from a handful of tests • Validates your automated deployment is working • Gives confidence to refactor • Helps focuses on building the right thing
32. It does look great over there!
33. Small Steps
34. What about load?
35. Improving metrics Image from http://grafana.org/
36. Improving metrics • How your system is behaving • How long you have got • Compare environments • See effects of releases
37. Automating load tests Image from http://inhabitat.com/
38. Automating load tests • Leveraging Cloud computing • Use same metrics as production • Monitor the clients • Not just steady state • Gives confidence to refactor
39. How about upgrading?
40. Cattle not pets Image from http://www.partnersforhealthypets.org/
41. Cattle not pets • Bringing up new on each release • Keeps you honest • Disaster recovery test on every release • Have done it multiple times before production
42. What about state? Image from https://en.wikipedia.org/wiki/Pinnawala_Elephant_Orphanage
43. What about state? • Treat data like the application • Version Schema changes • Apply updates as part of pipeline • Don’t test for first time in production
44. It’s just over that ridge!
45. Now we are getting somewhere Image from http://www.tbo.com/
46. Balancing improvement with delivery
47. What is most painful for business? Image from http://keepingbee.org/
48. Work from a single backlog Image from https://www.airport-pickups-london.com
49. Use Features as a vehicle to improve Image from http://www.photoshoplady.com/
50. Avoid long lived branches Image from http://www.arttech.ab.ca/
51. Keep paying off the debt Image from www.entrepreneur.com
52. When things are bad be relentless Image from http://www.mde.state.md.us/
53. Where did we get too?
54. Where were we after 18 months? • Delivering 2-3 times a week stress free • Changing the way the business worked • Really happy team willing to touch any part of the system • Starting to strangle the existing application
55. Other things we learnt along the way
56. The easy path ends in a ditch! Image from http://apsmithonline.com/
57. Don’t try and do it by yourself Image from http://content.lib.washington.edu/
58. Get the furniture right Image from http://kingsofficefurniture.co.uk/
59. The value in retrospectives Image from http://monteneyelearning.org/Image
60. Retrospectives cross site Image from http://physweb.bgu.ac.il/
61. It’s only feedback if you… Image from https://en.wikipedia.org
62. Information radiators
63. The book that describes what we did!
64. Thank you J