Developing and Deploying

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.

The problem

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.

More Project Requirements


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:

  1. It downloads the master branch of the repository into a new folder, accessible by Apache.
  2. It gets the latest database backup, exported by a cron job.
  3. It finds and replaces the original url ( at which the new domain that the staging site will be available ({something}
  4. It creates a new MySQL database and a new MySQL user.
  5. It imports the modified database backup into that new staging database.
  6. It writes wp-config.php and .htaccess files 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.

Future Work

Who am I?
I'm James Little, a software engineer and design enthusiast based in Boston, MA. I work at Stripe on the Docs team, and I build a search web tool called Stork Search.

Come say hello!
If you liked this post, come say so by signing my guestbook!

Made by James Little between 2016 and 2022.