Brendon Foxen (Channel 4) - Speeding up Software Delivery at Channel 4
-
Upload
dataloopio -
Category
Technology
-
view
326 -
download
0
Transcript of Brendon Foxen (Channel 4) - Speeding up Software Delivery at Channel 4
• Terrestrial UK broadcaster • First terrestrial on-demand service in the UK • We build, deploy and manage
– Websites – Web services – VoD Services – Device apps – Data services
• Ad funded commercial model
Background to C4
• We want to create the best personalised user experience
• To deliver the best experience we need to innovate and get enhancements into production efficiently
• Application architecture, tools, practices constraining us.
Business Problem
• Early adopter of cloud (circa 2009) • Cloud first strategy • Templated stacks via custom deployment
framework (Bash + xml)
Where we were…
• Monolithic programme metadata DB • Deficiencies in cloud management • High test and deployment overhead • Onerous release process • Dev dependency on sys engineering
Problems!
• Decompose the monolith • CI/CD approach • Self service and more automation • Change mind-sets • Promote shared responsibility
Strategic
• First class CI/CD orchestration tool • Integrate testing into an automated pipeline • Standardise development practices
– TDD • Swagger
– Framework use – Improve operational support within apps
• Metrics • Operations endpoints
– Docker implementation
Move towards CI/CD Practices
• Improved efficiency • Change & product lifecycle visibility • Better understanding of Docker • Happy people J
Outcomes
• Implement feature branching / toggling across our apps
• Fully self service project initialisation • Harvest metrics, store and expose • Docker clustering • Service virtualisation
What we’re going next
• Move towards continuous deployment • Canary releasing
– Backwards compatibility – Traffic shaping
• Scorecard deployments – Leverage metrics, central logging etc – Fail fast, fix forward
What we’re doing next next
• Highly distributed architecture – Dependency management – Inter process comms overhead
• Our experience with Storm – Fault tolerance
• Docker scheduling logic • Support model
Nuts we’ll need to crack