I moved the Bowdoin Orient site from a custom CMS to a WordPress-based system over a year ago; since that time, I’ve struggled to find a proper development and deployment workflow that made sense for the Orient. This year, as the Orient welcomes four new members onto its web staff, I’ve been working to ensure that the website could easily be developed and deployed.
The system I built was based on solving the core problem of WordPress development: that the disadvantages of using exclusively local or remote development outweigh the simplicity of those two methods. I wanted to ensure that we could avoid those disadvantages and fulfill other requirements while using the best best practices I know of. Furthermore, I wrote it in Ruby to familiarize myself with the language used most often at Stripe, where I interned this past summer.
WordPress makes it notoriously hard to set up staging environments. There’s configuration that takes place in PHP files and other configuration that takes place in the application’s database. Migrating the application from one server to another is so difficult that paid tools exist to do it properly. Local development either requires manually configuring daemons and local servers or installing MAMP. I wanted to build a solution that required as little local modification as possible, while still providing as much access to the code as possible.
The workflow should encourage code review and transparency. One deployment system is to have no deployment system, and just write all code on the server, live. This is known as “cowboy coding,” which is canonically bad.
The system should make it easy to write new code, but it should make it drastically difficult to write that new code on the actual web server. We use Git and Github for version control, and I wanted to ensure that an administrator could approve code changes before they made it into the live site.
The foundation of the project is a remote web server and database that hosts different instances of the Orient website. Also running on this server is a program that can automatically spin up and tear down new instances of the site and show users how to synchronize code between their local machine and the server.
When a new instance is created, the Running on a VPS is a Ruby application that keeps track of development environments, or devenvs. When a new devenv is made, the user specifies a subdomain, and the application performs a series of setup steps:
bowdoinorient.com) at which the new domain that the staging site will be available (
.htaccessfiles with accurate database and domain information.
When this is complete, users use
scp to copy the entire directory onto their
local computer. They can make edits locally, create new Git branches, and make
commits. As files are changed, developers can use
rsync to synchronize local
changes with the server. Developers also have full access to the MySQL database.
This lets developers have all the benefits of space on a VPS—server infrastructure is managed externally, nobody has to do any weird things with their hosts file to get domains to work, and the site is available everywhere—while also having all the benefits of local development—they can use whichever editor feels comfortable, run preprocessing steps locally, and can have a quick refresh-to-analyze cycle. This is the most optimal system I’ve found for setting up a hybridized local-remote development.