2

At work we're moving from no SCM to Mercurial. It's a bit of a learning curve, but after messing with it for two days I definitely feel more comfortable with it.

I still have one big, unresolved question though in my mind: Once code is finished, how do we handle the actual deployment?

Should we be running a copy of Mercurial on the production (live) server? Or should we set rsync or something up to sync from the repo to the web directory? What's the best practice here?

If we do go w/ just pointing apache to the repo, I assume this is okay as long as we're careful not to hg update to a different, non-stable branch? That still seems a little dangerous to me though. Is there some way to force it to only switch to certain builds?

Or is pointing apache to the repo just a terrible idea and I should be doing something else instead?

On a related topic, I've also heard some talk about putting any upgrade scripts (such as schema changes for MySQL) under version control so they can be ran when the version is deployed. But how would that even work as part of the workflow? I wouldn't want to keep it w/ everything else, because it's a temporary one-time use script...

Thanks for any advice you guys can give.

Improve this question
1
  • 1
    If you configure Apache to point directly to the repository working copy, be careful to deny access to the .hg directory. If you fail to do this everyone will be able to clone your complete source repository just by pointing to your website. Commented Jul 16, 2012 at 10:25

2 Answers 2

Reset to default
1

I recently discovered the hg archive command, so I think we'll go w/ this instead. I've written a bash script that changes to the head of the 'production' branch then archives it to a predetermined destination. Seems to work.

I'd still appreciate any feedback you guys have as to whether this is a good idea or not.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Yes, using archive for this is fine :).
0

I think pointing apache to the repo is definitely a bad idea, hg archive is ok if all you want is to take a snapshot of the dev files.

I find my development source files and a deployed application (even for a web app that doesn't need compiling) are usually very different, the latter being derived from a subset of the former.

I tend to use a shell script or a even a Makefile to "build" a deployed application in a subdirectory of the development directory, this could just be creating a directory tree and copying necessary files or could include compressing scripts etc.

This way you have to make a conscious decision whether or not to include a file in the deployed version, thus helping prevent accidentally leaving development utility files in an online application that could cause a security risk.

The only part mercurial plays is, for a major release I create a new named branch (eg: 1.5), development continues on the default branch. Subsequent bug fixes or patches can be transplanted to the release branch if necessary and if a bug fix release is made I tag the release branch with the new version (eg: 1.5.1).

Improve this answer

1 Comment

Hmm.. We've got about 200,000 source files though, so I'm not sure how effective a make file would be for us. We probably wouldn't assemble it by hand, and so at that point, we may as well do an automated archive of the thing...

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.