In yesterday’s post on version control, I briefly touched on the issue of development sites:
We’re also still working out how to handle (or not) staging sites vs production sites, particularly in cases where we’re working with an existing site… In general, we don’t use separate staging sites that mirror production sites but that’s something we’ll likely be changing, at least for projects on existing sites.
Since this is something that I’ve gotten a number of questions about over the last few months, I thought I’d go a little further into what we currently do and what I’m considering instead.
Right now, there are two different ways we handle development sites, depending on the particular situation. In both of these models, we use a plugin to handle hiding the site from non-logged-in visitors, as described in this tutorial.
|Brand new site and/or brand new hosting account
||Build right in the final installation of WordPress
|Replacing/ updating an existing site, on the same hosting account
||Build in a multisite installation that lives on my hosting account
This has worked well for over a year. It lets us work in a fairly non-disruptive way and allows us to make development work available to the designer and/or the end client (which developing locally would prevent).
It also has some downfalls. While my multisite installation is a decent place to build themes, it isn’t exactly the same as the final single site installation and in some cases those differences can be problematic. It also requires that all the plugins are installed centrally, which is sometimes a pain, and it can be a hassle to transfer everything over when we’re ready to install the final site.
In the Future
It seems to be a pretty popular notion that it’s always essential to have both a development site and a production site, where you test all changes on the development site before pushing them live on the production site. While I get the theory behind this, it really just doesn’t fit our projects or our needs for the following reasons:
- We typically aren’t actively involved in a site for very long after the launch, so we usually aren’t pushing changes to a live site.
- In cases where we do go in to make tweaks to a live site, it frankly would increase the cost quite a bit in most cases to first create a development mirror, test the changes there, and then deploy to the live site – a cost that might be prohibitive for many of our smaller clients.
- In those same “tweaks” cases, most of the tweaks we make are extremely low-risk. While I know this is kind of a poor excuse and that any tweak can be riskier than you (or I) anticipate, it certainly does come into play in a cost/ benefit analysis.
For these reasons, I’ve found that on the balance it doesn’t make sense to have development mirrors for most of our projects
That said, I’ve been thinking about making some shifts in our methods in two cases.
Case 1: Redesigns
As mentioned, most of our theme work for redesign projects happens on my own installation and hosting account. I’m likely going to start replacing this model with development installations on the client’s hosting account in almost all situations. This will probably mean creating a subdomain installation of WordPress and using that for our development work.
This will be beneficial in a number of ways – it won’t be a multisite installation, it will be in it’s final resting place from the outset, we can easily change the domain to read from that subdirectory when we’re ready to launch, and so on.
On the other hand, it does require an additional installation on the client’s hosting account, something that may make some clients nervous (not that it should, but it will), and that may be tricky for some low-budget shared hosting accounts that put limits on databases, subdomains, and the like. It also takes the development site out of our control to a certain extent, which could theoretically be an issue if we ever had a dispute about payment.
Case 2: Ongoing Clients
The other use case for a development site is clients that we are going to work with on an ongoing basis. I’m getting ready to launch two new ongoing maintenance and site strategy services* – in those cases we will want to have a more controlled process for testing out changes and updates since we’ll be managing a lot of that for the client.
I imagine in those cases we’ll take a similar approach to redesigns and create a second development install on the client’s hosting account. The open questions about this model mostly revolve around keeping the installations synced in a useful but safe way (especially the databases), so it’s something I’ll be doing more research about as I roll out those services.
So that’s our current “state of development sites,” as it were. If you’ve got a model that’s working for you, or if you want to school me on why I should stop making excuses and always use a development site, please share in the comments.
*If you want to find out more about these services when they launch, you can sign up for email updates – I’ll announce things there before I post them here, and some services will be limited in availability. You’ll want to select at least the general news option.