How to transfer files to production?

Question

We are a group that started working on a fairly big website with an existing codebase. We have a test and a production server.

Our idea is to have a test repository with a number of devs having push access to; and a blessed repository that only a few can push to. The blessed repo is supposed to be always stable and represent the latest production version.

How can I automate the process of transferring the files into production? Is it bad to have the production files under version control? That way, pushing to the blessed repository would mean deployment. But, what happens when there are merge conflicts? Will the production server break until it is resolved?

Answer 1

To put it simple:
The push process in itself should be fully automatic. Whether you have some custom script, or you simply pull from the "blessed" repo to the production environment. That is up to you. You should just have something automated, because automated processes can be made reliable (as opposed to uploading files by hand and such).

However, the push process should be triggered manually. You push your updates, and once you feel confident, you tag it as a release candidate and pull it to your test environment (that would ideally be as similar to your production environment as possible). Once the RC is tested, the push can be initiated.
As of today, nothing else can give you, what human testers can.

This sounds a little slow, in the sense that the feedback loop is a relatively big. But for proper testing, it is important to take an fixed snapshot, which is then examined for 24-48h (or maybe more, depending on the size of the project). The opposite is a scenario, where you find a lot of bugs right after pushing and you try to patch it up with some quick fixes that introduce new bugs.
You better make a release with known bugs (of acceptable severity), than one with unknown bugs (of unknown severity).

Answer 2

I learned a lot about deployment from looking at how Capistrano operates. I was working with RoR at the time, so it was a logical choice and although I never quite got it to behave for the project I was working on, the way it performs automated updates was very useful.

You may be in a situation where you can use it directly even - it isn't necessarily tied to Rails - but if not, the way it behaves is certainly helpful.

Answer 3

Depending on what platform you are using, there are lots of tools out there that might make sense for you to use to automate production releases. I work in a .NET shop so we've been using NAnt (although MSBuild is a better option nowadays). Java has Ant, and possibly other things. Ruby has things like Rake. Then there are continuous integration platforms like TeamCity and Hudson that can be used for managing releases as well.

I've never seen or heard of having the prod code directly in a separate source control repo but that could certainly work. Like back2dos said, the key is to automate. We have our build scripts designed to check out from source control, build, and push to staging environment for testing. Then, when we like how staging is working, the scripts copy from QA to Prod.

My recommendation is to look at the tools out there and pick one, and then design a process that will work well with the selected tool. Don't try to reinvent the wheel too much - this is a very solved problem.