deploy website from version control - export and symlinks?

Question

I am a lone developer. We have a couple of websites hosted on a web host. The svn repository is also on the web host. In house, we have a development machine, which is a close-enough replication of the live environment.

For the live website, I have an export from subversion, appropriately named with the version number. The live website's document root is actually a symlink to that directory. That way, I can easily roll back or forth to exported versions with no downtime simply by changing where the symlink is pointed.

When it comes time to actually deploy, I will export a version of the trunk to a subdirectory of the live website, as a staging area, and do some testing. That way I see how it actually behaves in the live environment, without changing anything that users see. Then if everything looks okay, I'll do another export to the my account root and change the symlink ( and test again! )

Is this overdoing it? What are other ways of doing it?

Answer 1

I think this is exactly the right way of doing it. Looks ideal to me: Live updates come as a fully tested release, changes are well documentable through commit messages, rolling back (and forth) is easy and the switch from one version to another is atomic so there is no downtime. I strive to do it the same way with every project.

What is your question? Are you unsure about something? Is it not working out for you? If so, what part of it exactly?

Answer 2

It's kind of what I've doing for the last couple of year for a couple of projects -- and never had a single problem with that way of doing things.

The possibility of "rollback" with the symlinks might be seen as a bit overkill, yes... But the day you need it to save the website on which you deployed a version with a critical bug, you really appreciate having that ability !
I've used this something like 2 times in 3 years -- but, each time, it really saved the day ^^

One thing seems odd to me, though : if I understand correctly, you are testing the new version of the website on the live (production) database ?

If so, if there is a bug in the application, you could destroy your production database -- which, obviously, would be bad.

I would use another database for that testing environment, personnaly -- just as a security measure.

Also : you are doing a lot of tests, which is good... But why not automate some of those ?

It would allow you to test faster, more often, and you'd spend less time testing, and more time developping ;-)

Answer 3

There is Capistrano, which helps you in this process. Using SSH and keys, it makes the process pretty seamless to deploy changes and such. While this is a ruby app, you can use it still to deploy PHP or other applications, take a look here for some info

And this article talks about it, using a shared folder along with your release folder. The shared folder can hold config files for your individual deployment server (URL, DB connection, etc) as well as assets that are uploaded during the life of a website and aren't in svn. You can have Capistrano handle this for you also.

While someone not knowing the setup might have a bit of difficulty first seeing this, it really makes deployment easy. I think what Capistrano does is pretty simple and could probably be written in another language to handle your specific scenario.

And another idea to tie this into SVN, or any repository. Is to use their hooks to execute these deployments. i.e. every commit to trunk will update the dev server. And a branch will push it to your staging environment.

But this link does a great job of showing how to set up that type of environment. I think what you have set up is good practice and isn't done enough. The only thing that can help you out is automated deployment to different environments and scripts to help with the setup of your new deployment.

Update ::
Also, I'd like to note, SVN can handle symlinks. So if you are doing deployments on Unix based servers you can just put in the symlinks in your repository and use a relative symlink.

So if you have

./releases/200912231043
./shared/uploads

You can put your symlink as

./releases/200912231043/uploads -> ../../shared/uploads

This will give you an easy way to manage assets not in svn without using a lot of scripts do deploy. You can now just use a commit to deploy to your dev and/or staging.