Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

3 Answers 3

up vote 6 down vote accepted

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).

share|improve this answer
    
So having a repo on the production server is OK? When I said automation, I meant that in case there was no repo on the production server (in other words, there would be testing and blessed repos, but not production). Of course, the human testing can not be automated, it's not what I'm after. –  Tamás Szelei Jun 10 '11 at 10:13
1  
@Tamás: It might be ok to have local checkout of the blessed repo on your server, if that is what you mean (apache (or any other decent webserver) makes it easy to make the git related files inaccessible from the outside). However you could easily just make an "export" of it. There is no point of having files in your webroot, that don't belong there. –  back2dos Jun 10 '11 at 10:20
    
Err-... So how would you know exactly what the unknown bugs of unknown severity are if they are... unknown? –  Spoike Jun 10 '11 at 13:15
    
@Spoike I think back2dos is simply advocating testing thoroughly, using fixed releases that don't have "quick n dirty" fixes that are untested. –  Max Jun 10 '11 at 13:29
    
@Spoike: In 24-48h you can turn a lot of unknown bugs into known bugs. Also in 5 minutes, you can turn a known bug into a lot of unknown bugs. This is called a quick fix. –  back2dos Jun 10 '11 at 14:32

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.