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

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.