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 →