By Thom McGrath on
This concept is so simple and easy, I'm amazed I had not yet thought of it. See, I keep a subdomain of this website which I use as a sandbox. I draft new designs or concepts with it. But it's always been a complete pain to bring the sandbox to the live site. I don't want to overwrite too many or the wrong files, and I made the mistake of keeping subdomain files inside my www directory. It's a mess, and I know better now.
When I started with REAL Software, they were working towards keeping their website under version control. I finished the job. Their start, while not perfect, was a good start that gave me the idea for the right way to do it.
The way it's setup now is brilliant. Making changes to the website and making them live is insanely easy. I'm going to be setting this up for my personal website. Here's what you'll want to do.
You'll need a couple of things. Most importantly, you need SSH access to your webserver. If you don't have this, you're dead in the water. My host,
Made2Own [Update: Made2Own is out of business], has cost-effective shared hosting plans (like I'm using now) for around $8-$15 a month. You'll need their developer package which is an additional $5 a month, but the price is excellent and I have been very happy with this host - and believe me, I've been through plenty.
You'll also need a repository. You can technically host it from your webserver, which will have the fastest data transfer times, but I'd recommend using a 3rd-party. Why? Backup. By keeping your repository elsewhere, you have an automatic backup of your website files. Of course, that won't help your databases, but it's one less thing to worry about. I'm likely to use Beanstalk myself.
I'm going to be making some assumptions here. This is not a subversion tutorial. There are plenty out there. I also do not know where your repository is kept. So instead, just follow along with the concepts.
You need to first import your current website to the repository. Subversion's import command makes that easy. Make certain you import your website into your trunk because branches are very useful for this concept. After that, you need to do something scary: break your website. We can do this with minimal downtime though. Do not simply delete your www dir and do a checkout. That will take your website down for a while. Instead, checkout your trunk to a temp dir, like www_new. Then rename www to www_old and www_new to www. You'll have nearly zero downtime. Test your website and have a blast. If all went well, you can remove www_old.
Now, you can setup a sandbox. If you don't have a sandbox subdomain, create one. Do not put the subdomain's contents in the www dir. That would be pointless. If you're using cPanel, delete the dir that cPanel creates for you. Next, do a checkout of the trunk to create the sandbox directory. Bingo, you should have a perfectly mirrored website for your sandbox. Test it out. If you get errors, you probably did something foolish and hard-coded your directory names. If you've ever moved a website before, you'll learn quickly to use an environmental variable such as DOCUMENT_ROOT, or as I do, define your own in the .htaccess file.
Make your changes to sandbox, commit them, then do an update on the www. Bingo, you've just brought changes to your live server.
Now for some advanced tips.
Create an FTP login to only give you access to the sandbox. That way, you can only update the sandbox site. There is no harm in updating the public version, since either copy can commit changes, but it's best to work in this manner.
Use the svn propedit command to ignore your .htaccess file. This file will be completely ignored, so you can have different versions for the sandbox and public sites. Then, you can use a SetEnv command in each .htaccess to make an environmental variable IS_STAGING_SERVER. Your code can then reference this variable and react accordingly.
You can create a third subdomain, call it volatile, and use that for a completely separate branch of development. Maybe you're working on something that will take weeks to do, but you'll want to be able to update your website in the meantime. Creating a branch will allow you to do so, without interrupting the main site. When you're ready, you can merge your branch into the trunk and continue with life.
A word of caution: your .svn directories will be visible to the public. First, if you have not yet done so, turn off directory indexing. This is a generally bad thing. It'll only help a little though. If you have access to your apache config, you can use a
<DocumentMatch> directive to block access to those directories. If not, you'll want to use your .htaccess file and use a Rewrite to simply change any URL containing .svn to something else - like your main domain. You want to match more than just URLs ending in .svn, because snoopers can access the files directly.
Lastly, if you're on the Mac and not using Coda, get it first. It's the best damn web IDE I've ever used, and the built-in terminal will allow quick publishing.
Now go create havoc on your sandbox! If you cause trouble, you can just use a revert command! There were many concepts explained here, so maybe I'll go into more detail in the future, but here's something to chew on for now.