My mercurial dev/prod workflow using clones

Most of the people whom I work with are very confused about repository and work-folder of mercurial. If they are comfortable with that then they are hesitant to use named branches. Hence I stopped using branches for maintaining my dev and prod code streams. Instead settled on clones (forks on Bitbucket/GitHub). I find it easy to explain to all kind of people and easy to work. I was thinking about writing an how-to for the same. But blog makes much sense.

dev-prod-clone model I have a development repository for a ‘project’ called ‘proj-dev’. Every bit of code which makes sense will live here. Every team member has push access to this project. Lets say we developed over several months. Now we have reached some sane level where we could show it to our family. We use tags to bookmark stages of development. So after passing all rc.x.x.x (release candidate aka test releases) stages, we have reached v.0.1.0. Which probably is our alpha production release.

Now I clone/fork the ‘proj-dev’ to ‘proj-prod’. Only support and system admin team has push access to ‘proj-prod’. Anything that has to get onto production servers has to come from ‘proj-prod’. Hence we deploy the production code from ‘proj-prod’.

From here on we have two tracks. Click on the image for bigger resolution.

Track 1 – ‘proj-dev’ :

  1. May not be stable
  2. All developers will have push access to this repository
  3. Regular development continues on this repository
  4. Any developer can pull, production fixes from ‘proj-prod’ or accept pull requests
  5. Once all the features reach stable state and production ready, team marks it as v.x.x.x

Track 2 – ‘proj-prod’ :

  1. is most stable
  2. Direct commits to this repository are done only as part production fixes
  3. All production fixes are sent as pull request to main ‘proj-dev’ repository
  4. Any developer can pull ‘proj-prod’ into their repository
  5. Any production ready code (v.x.x.x) on ‘proj-dev’ will be pulled into this repository. Production deployment can be done only from this repository.

This is what I follow as a team lead. It keeps the work-spaces separate on my developer’s machine. It also keeps repositories separate. I guess its easy to understand or I find it easy to explain it to my team. Do you think its easy to follow?

I will probably call it the dev/prod clone model :)

You may also like...

2 Responses

  1. Veera says:

    Instead of the separate repos, why can’t we use branch? Is there any drawbacks that you faced by using branches (other than the difficulty of explaining them to people)?

    • Thejesh GN says:

      No problem with branches. I could have used it. Except for
      – I couldn’t maintain different ACL for it
      – People who come from CVS/SVN background are scared about branching and merging branches

Leave a Reply

Your email address will not be published. Required fields are marked *