Last January Eric Ries was kind enough to host a continuous deployment breakfast at Wayfair.
It was a great discussion, and we were happy to learn that we have independently arrived at similar conclusions over the last 9 years, and built a system that aligns closely with some of the principles that Eric advocates. The learning aspect and continuous improvement approach to the Lean Startup formula is an integral part of our method here, and why we resonate with Eric’s message.
Today Eric is back in town and speaking at an event at the Harvard i-lab.
As a way to help spread the word about continuous improvement, the Lean Startup movement and our new engineering blog describing how those fit in at Wayfair we are going to be giving away 10 copies of Eric’s book.
The first five blog posts mentioning the new engineering.wayfair.com site gets a copy of Eric’s new book. Post a comment below with a link to your post so we know where to look. To help get the word out, tweet this post and we’ll pick 5 random tweets to get books as well!
The architecture of the deployment system
In the last post I explained our deployment system goals and the basic architecture.
Now that stage is set, let’s get into the details of the architecture from the deployment server perspective. As we designed the deployment server we wanted to keep the interface and the logic and requirements of the server itself as simple as possible.
The deployment server is running on our standard FLAMP stack. (FreeBSD, Lighttpd, APC, MSSQL/MySQL/Memcache, PHP). We’ll save more details on those decisions for a later post.
On the deployment server there is a configuration file that defines each application and the required details to deploy it. It defines the basic things like friendly name, allowed code reviewers, repository name and repository folders to be included. Continue reading
The Wayfair Engineering team isn’t really on the continuous integration bandwagon, but our deployment model comes pretty close naturally because of our desire for continuous improvement.
In the block to the right of the homepage we are displaying the number of code deployments that engineers at Wayfair have done over the last 7 business days. This is a count of deployments to our new environment running our customer facing websites. This represents only a small portion of our total code base, but is a good display of how often we are improving the storefront for our customers. Internally we track a lot of other statistics about our deployments as well, like who did the deployment, the internal ticket number that the deployment was for, the SVN revision that was deployed, and who reviewed the code. Continue reading
Part 1 of a series on Code Deployment at Wayfair
Code Deployment at Wayfair has always been about creating the
fastest and most friction free deployment process possible .
Wayfair.com Architecture History
For the last 9 years our platform has been primarily a Classic ASP
environment on a Windows Server stack. In order to facilitate code deployment in that environment we wrote a script that replicated file changes out to the webfarm once they were FTPed to a central server. Unfortunately as the webfarm grew, so did the amount of time it took to push code, and in the event of an issue, the time it took to roll back code. In this environment it took about 15 minutes to replicate code out to all of our servers.
From the chatter on the inter-webs and talks at Velocity and other conferences I’m sure a lot of people would think that is “fast enough”. For us this was unacceptable, since changes that had to go out together were not guaranteed to replicate at the same time, and with upwards of 50 deployments a day we needed to see our changes more quickly. Continue reading
I recently saw this post on Etsy’s blog and found it inspiring – you don’t typically see retailers (or any companies for that matter) sharing performance data. Even more impressive is the fact that they posted this on their primary blog as opposed to their engineering blog. To me this says that Etsy really cares about performance, and wants all of their customers to be aware that it is a priority. After reading that post I immediately wanted to share some Wayfair data – and this is my attempt to do that (maybe I can get it cross-posted to our main blog ).
Here at Wayfair we care a lot about performance, and the business case for having a faster site is well documented. To keep tabs on our site performance we have synthetic monitoring tools like Catchpoint, real user monitoring tools like Coradiant (now a part of BMC software), and our own home-brew monitoring instrumented in our ASP and PHP code. We have also had great success using StatsD in conjunction with Graphite. Continue reading
Wayfair was founded in 2002 by engineers and is, at its heart, a technology company — one that’s focused on solving the difficult problems associated with selling a zillion products online (well, officially just over 4 million at the time this was written).
The retail industry is not new — it’s been around for over a thousand years. But the Internet is now revolutionizing retail, and we’ve had the good fortune of being at the center of that revolution for over nine years, so far. It’s a business of a thousand details, which all add up to present significant challenges in terms of logistics, scalability and performance. Continue reading