How We Deploy
Even though we’re a startup, Well.ca is a pretty big ship. Users just see the public website, but there are many, many other pieces behind the scenes. Our customer care team has their interface into orders and billing. The merchandising team is constantly adding new products using their own interface. Marketing wants to be able to keep track of what’s selling, and how our various campaigns are working. And that’s just a small part of the office. The warehouse is its own war zone, complete with pick and pack systems, postage interfaces, and re-order processes. To put it simply, there are a lot of moving parts to a successful e-commerce site, most of them invisible to the public. They’re all vital to the well-being of Well.ca, and they’re all ultimately the dev team’s responsibility.
So, how do we do it?
Our development team works off an Agile style process, with weeklong sprints. At the end of every sprint, we do a rollup of completed work and deploy to production. We also have a structure for deploying hotfixes mid-sprint, which I’ll cover in a bit.
We use git for source control, which lets us branch to our heart’s content. For most of our projects, we use a master and production branch model, in addition to the usual topic branches.
Topic branches are merged into master once they’re tested and reviewed. To do our weekly rollup for production, it’s a simple matter of merging master into production. During a weekly sprint, master is always ahead of the production branch by exactly the work done (and merged) so far that week (modulo any hotfixes done during the week).
To handle the actual deployments, we use the trusty capistrano, pared down via our own minicap project. In addition to production deployments, we also use capistrano to load code onto our test server cluster, which I’ll be talking about in a separate post. We favour driving automation via rake tasks as opposed to putting a lot of logic in capistrano; where we have the choice, we make rake smart and capistrano dumb. It works well.
I mentioned hotfixes before. We do hotfixes by branching off of the production mainline to make our fix, then merging that branch into both production and master once the fix is complete. This ensures that production is never ahead of master, which conceptually means that there is never code in the production environment that isn’t in our development mainline. You can see this in the above diagram.
So that’s how we manage and deploy a single project. Life is never that simple, however, and of course Well.ca is bigger than any one project. Our code is split into two main projects, which we term frontend and backyard. Frontend is the site that you’re familiar with. It encompasses our public site, catalog, and checkout systems. Backyard contains most of the web interfaces Well.ca uses internally, including systems for customer care, merchandising, marketing and accounting. Although our two main projects share a lot of code, we treat them as separate entities, and they get deployed on different schedules. We also have a number of smaller projects to handle things like affiliate management and live chat, and these also run on their own deployment cycles.
