Adopting Continuous Deployment at Lyft

All organizations, regardless of size, need to be able to make rapid changes and improvements in their constantly growing systems. How can we handle all this change while maintaining a reliable product? 

In 2018, Lyft operated a few hundred services. Deploying a change was difficult: a developer had to take a lock, read a runbook, then execute several manual steps, all while monitoring for potential problems. This took time, resulting in large, delayed, deploy trains, and ultimately, reliability issues. Today, Lyft operates over 1,000 services, and, by adopting continuous deployment, more than 90% are now automatically deployed to production, with no manual intervention. This has significantly improved reliability, freed up developer time, and sped up our ability to ship changes. 

I will share the details on our journey to continuous deployment, the benefits, challenges, and lessons we learned along the way:

  1. The benefits, obvious and maybe non-obvious, of continuous deployment.
  2. How to set up your organization’s deploy culture to successfully adopt continuous deployment.
  3. How to design a pluggable system of checks to automatically detect issues in deployments before they become widespread.
  4. How we measured to ensure we improved reliability and developer productivity through continuous deployment.


Tom Wanielista

Senior Staff Software Engineer @Lyft

Tom Wanielista is part of the Infrastructure team at Lyft, where he has focused on improving reliability in production by speeding up the deployment feedback loop. Prior to Lyft, Tom worked on Infrastructure in the Fintech space, where he was responsible for building tools to allow developers to safely deploy changes while keeping the stack secure & compliant. Tom studied at New York University where he received a BA in Computer Science.

Read more
Find Tom Wanielista at:

From the same track


Dark Side of DevOps

Monday Oct 24 / 02:55PM PDT

Topics like “you build it, you run it” and “shifting testing/security/data governance left” are popular: moving things to the earlier stages of software development, empowering engineers, shifting control definitely sounds good.

Mykyta Protsenko

Senior Software Engineer @Netflix


Crypto Agility: Risk Management For When Your Service Can Take Down Everyone

Monday Oct 24 / 04:10PM PDT

In May 2022 the White House released a National Security memorandum

Anvita Pandit

Senior Software Engineer @Google


Architecting for Change at Scale Presentation 4

Monday Oct 24 / 05:25PM PDT

Details coming soon.


Architecting for Change at Scale Panel

Monday Oct 24 / 11:50AM PDT

Details coming soon.


Unconference: Architecting for Change

Monday Oct 24 / 01:40PM PDT

What is an unconference? At QConLondon, we’ll have unconferences in most of our tracks.

Shane Hastie

Director of Agile Learning Programs @ICAgile