Continuous Deployment - Case Study at WIX
Upcoming SlideShare
Loading in...5

Continuous Deployment - Case Study at WIX



Continuous Deployment - Case Study at WIX

Continuous Deployment - Case Study at WIX
By Yaniv Even-Haim
@ Agile Israel 2012



Total Views
Views on SlideShare
Embed Views



6 Embeds 118 91 20 4 1 1 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Continuous Deployment - Case Study at WIX Continuous Deployment - Case Study at WIX Presentation Transcript

  • Continuous Delivery @ Wix Yaniv Even-Haim VP R&D Agile Israel 2012
  • A story on Wix time machine
  • Wix Intro
  • Wix in numbers• 22,000,000 registered users from 233 countries• ~1,000,000 new users every month• ~ 25,000 new websites every day• 16,000,000 web sites• 650,000 mobile sites• Over 120Tbyte of users media files• More than 1 Billion users media files• 230+ servers in 3 data centers• 270 employees• 80 R&D people
  • Time machine event =• Deployment capabilities : “no click” deployment – Dozens of services , 230+ servers over 3 Data Centers• Backward and forward compatibility at the extreme field test case – Mixed versions of services / DB with no service downtime• Empowerment – The power we give to individual• Risk taken and failure embracement
  • CD is business concern Revenue per month201…201…201…201…201…201…201…201…201…201…201…201…201…201…201…201…201…201…201…201…201…Traditional “Economies of scale” threaten by cloud technology Be faster than small startups CD “Economies of Agility “ = Velocity X Size
  • CD is culture & mindset• Trust the developers – Empower developers to change production – Developer knows his system best• Automation as a default choice – no more “is it worth to automate ? ” – Everything should be automated• Welcome to the twilight zone – Product/Dev/QA boundaries are going down – Everyone need to care about everything – Less formality : Corridor - IN , Meeting Room - Out
  • Get out of thought land make sure you building the right it before build it right• The Law of Failure – Most new “its” will fail even if they are flawlessly executed• Invest less, in touch less , better ability to admit it fail – Data beats opinions - Let the market decide
  • Some Best Practices• Everyone develops on the Trunk/Master – Release frequent – small pieces of functionality – It’s the developer responsibility not to break anything• Code can get to production at anytime – TDD & integration test• Use Feature Toggle – Unbaked new code can go to production – no harm done – New code goes with a guard – use new or old code
  • Some Best Practices• Backwards and Forwards compatible – Each component has to function with latest, next or prior version of other components (including DBs)• Gradual Deployment & Self Test – Deploy new version to one server and perform self test. If it passes, continue deployment to other servers• A/B Testing – Open a new feature to a percent of your users. Is it better? – Deployment is an engineering decision
  • CD – prepare to invest…..• Dev infrastructure - Refactor , Refactor, Refactor• Testing infrastructure & know how• Deployment infrastructure & tools• Automation , Automation , Automation• Monitoring (business and technical) – hundreds of aspects – thresholds use is a Must – Monitor business KPIs – Internal & external – Endless Tuning & learning
  • Wix Developer Lifecycle
  • New Relic - Monitoring
  • Application dashboard
  • Application dashboard• Self-Test – Can my application function?
  • Chix – Staging Deployment
  • Scaling challenges• Deployment complexity – Development velocity  more services – Development velocity  Richer use cases -> more dependencies• Development complexity – Very hard to work on master/trunk with 30+ dev on same code base – backward and forward comptability is not easy• Wider set of technologies ,tools & languages – Higher level of infrastructure investments – Harder to have all around players – More communication/sync required
  • Scaling challenges – Cont.• Complex Matrix Management - People moving between teams frequently - One can have several managers on different tasks - Hard both to managers and employees - Everyone should master the matrix management skills• Product MVP practices – How to define a product that can be development in a day ? – And that can win in a/b test … It is not all or nothing game - it is continuous journey