Another awesome talk by the guys at LeanLA and IMVU!
Here's the blurb about the talk and the really knowledgeable speaker:
"Continuous Deployment takes continuous integration one-step further, where every commit goes live to production servers. When this process is described it is frequently met with skepticism around site reliability and the ability to scale a business this way, but it works, it scales (with challenges) and it is embraced by the entire organization. IMVU is a leader in Continuous Deployment, with over 5 years of experience scaling this process to support a technical staff of 50 and a business of more that $40 million in annual revenue. Brett G. Durrett, Vice President of Engineering & Operations for IMVU explains the basic mechanics of Continuous Deployment and discusses the value it creates for the entire company. Specific topics that will be covered: Attendees will understand that releasing to customers 20+ times per day is possible and that it does scale from individual developers to large companies. In addition, they will understand how they can make Continuous Deployment successful at their company, from both a technology and cultural standpoint.
Brett G. Durrett has over 20 years experience leading development of software and systems ranging from large-scale Internet services to video games. He serves as VP of Engineering at IMVU where he leads the engineering and technical operations teams and was responsible for the operations infrastructure that successfully scaled from two machines to over 700 servers. Prior to IMVU, Brett served as the Director of Engineering, VP of Operations and General Manager for the virtual world at There.com. Brett was also co-founder and CEO of Asylum Entertainment, a game development company."
You can watch the talk (in two parts) and see the slides above. I'm pretty much sold on what Brett preaches and am thinking of how to implement continuous deployment in my current projects. He says that having little code and process in place puts you at an advantage, though I'm still wondering how to put in the right infrastructure to have all the tests and deployment run as smoothly and automatically as they do (and how much to prioritize this process infrastructure work around other initial start-up goals).
My notes on the talk are below. Overall, I learned a lot and very much enjoyed hearing Brett speak.
amount of time you need to run test depends on volume of people going through funnel
all work done on trunk (no work on branches)
continuous integration: they use buildbot, others use hudson, jenkins, atlassian
everyone emails changes to the change list (basically everyone in company) with before and after state and people can catch problems
they have one monolithic code base
don't have anything that ensures they have test code coverage automatically
Getting Started (story):
if new code breaks something old, must write test to catch that
expect some hurdles:
added query killer (issues kill statements on long queries; better to have code die than DB to be overloaded and take down everybody)
schema changes on large tables (they use mysql):
hard to work with outsourcers who build over several days (impossible to integrate)
build system itself is critical business function; keep metrics on build system (web dashboard of build process)
integration with A/B testing inside the code (nice slide with pseudocode)