This is the Engineering Culture Podcast, from the people behind InfoQ.com and the QCon conferences.
In this podcast Ben Linders, an InfoQ editor in the Culture & Methods area, spoke to Lianping Chen of Paddy Power about their adoption of continuous delivery.
Key Takeaways
- An introduction to continuous delivery
- It is possible and feasible to go faster while maintaining and improving the quality of the products being built
- The benefits from adopting continuous delivery include reduced time from completing development to getting product into production and getting faster customer feedback
- The way you elicit and represent requirements also needs to change when adopting continuous delivery
- Implementing continuous delivery needs significant investment in time and money – don’t underestimate the costs involved and plan the adoption to deliver benefits early and get some quick wins
Subscribe on:
Show Notes
- 0m:05s - Introductions
- 0m:20s - Overview of continuous delivery
- 1m:10s - Why continuous delivery matters in today’s fast moving business environment
- 2m:25s - Going fast does not mean compromising quality
- 2m:54s - How Paddy Power got started with continuous delivery
- 4m:45s - The value of learning that you’re not working on the right thing early; rapid feedback loops
- 5m:15s - Using a Kanban board to make bottlenecks and blockages in the flow visible
- 6m:40s - Initial benefits from adopting continuous delivery included reduced time from completing development to getting product into production and getting faster customer feedback
- 7m:44s - Examples of the type of feedback received and the impact it had on product development
- 9m:40s - The value of trying things quickly, showing them to customers and getting their feedback
- 10m:20s - Following all the practices mentioned in the book by Jez Humble and David Farley
- 10m:45s - The way you elicit and represent requirements also needs to change when adopting continuous delivery – break them into small chunks which deliver business value
- 12m:00s - Architecture approaches and practices must also change. Design the product to allow for incremental delivery
- 12m:30s - Automated deployment is crucial – remove the manual steps in the deployment process
- 13m:30s - Zero downtime releases are necessary
- 13m:45s - Building an automated testing framework and design for testability are important to implementing continuous delivery
- 14m:40s - Example of a practice which inhibits testability is putting code in stored procedures
- 14m:57s - Mandating that for code to be checked in, it must have accompanying automated test cases
- 15m:50s - The need to change processes outside of continuous delivery to support the new way of working, especially around change authorisation
- 18m:20s - The importance of taking a holistic view of the development process from ideation to deployment and customer feedback when adopting continuous delivery
- 18m:45s - Examples of benefits achieved: reduce release cycle time from months to days, the ability to automatically provision test environments and increase the frequency of testing, improved quality and reliability of the product which results in vastly reduced time spent on bug fixes
- 23m:20s - Going faster with much, much better quality – it seems counterintuitive yet is demonstrably achievable
- 23m:35s - Important lessons learned – it’s not about the technology and automation, it’s about changing people’s behaviour and organisation culture
- 25m:20s - Things he would change if starting again, mainly around the specific technologies and platforms
- 27m:20s - Advice to organisations looking to implement continuous delivery – focus on business value, identify the pain points in the deployment lifecycle, address the pain points and use that to help make the cultural and organisational changes more acceptable
- 29m:57s - Implementing continuous delivery is a significant investment – don’t underestimate the costs involved and plan the adoption to deliver benefits early and get some quick wins
Mentioned:
