CODEWITHSUNDEEP
mercurial
monkeylytics
monkeylytics

Reputation: 51

Simple mercurial webdev repo setup: features vs. fixes

I have inherited a Mercurial system for a basic web site, but I’m new to Mercurial and am just the temporary site babysitter until we find somebody a lot more competent than me. But in the meanwhile, I could use pointers on how we can keep our feature development separate from quick bug fixes.

Currently, we have 3 basic environments: individual developer environments, staging, and production. Each environment has its own local Mercurial repo. A single bitbucket repo acts as the master repo that every environment pushes to and pulls from.

The problem is when someone is working on code that is unfinished but then needs to submit a quick bug fix that needs to be deployed quickly. If the developer has committed changes to the unfinished code and commits the quick bug fix and does a push, all that code goes into the bitbucket repo.

Judging by what I’ve researched so far, I can get by with a development bitbucket repo (for slower development) and a “stable” bitbucket repo (for fixes that need to happen now)

In this situation, on our dev machines, we’d do most of our slower dev code in our local dev repo which would be cloned from a local stable repo. When we wanted to share unfinished code, we’d push/pull to bitbucket dev. Other developers could push/pull from their local dev to bitbucket dev to keep their local dev environments in sync or merge code.

When we’re ready to push it into production, we’d push the code from our dev environment into bitbucket main and then pull it into staging for testing. If it looked good, we’d pull the bitbucket main repo into production. Later, we’d pull the bitbucket main repo into our personal stable repos to keep them in sync and then pull from the personal main repo into the personal dev repo to get that in sync.

If we’re in the middle of incomplete code in our dev environments but have to make some bug fixes quickly. We’d do the bugfix in our personal stable repos which should be free of any incomplete code, push the local repo to bitbucket stable, and then pull it into production. Then we’d pull bitbucket stable into our personal dev environments to keep it in sync with production but still preserving our unfinished code.

It feels like there’s a simpler way of doing this that I’m not understanding. Any advice would be greatly appreciated.

Upvotes: 0

Views: 63

Answers (1)

Lazy Badger
Lazy Badger

Reputation: 97282

The problem is when someone is working on code that is unfinished but then needs to submit a quick bug fix that needs to be deployed quickly.

This is a question of used workflow and (missing) management, sorry. I see at least 3 weak points in current state

  • (Unrelated) Why 3 repos instead of single repo with special named branches?
  • Why, with switching task workstyle, MQ extension not used as mandatory tool?
  • Why all development happens in default branch and named branches are not used?

I, as PM in this situation will evaluate two possible ways and implement after testing any of (or combination of both)

  • MQ extension for single-branch mode must be used for any WIP. Only finished and tested changes can be converted to changeset(s) (and, thus, can be pushed to public)
  • Single-branch mode replaced by "Branch per task" workflow (any task - new named branch in developer's repo, merged later to default) and default push-mode "all branches" replaced by "push only specified branches": only ...-b default in case of separated repos, -b default -b STAGING -b PROD in case of single repo with separate branches per target /DEVEL, STAGING, PROD/. In case of -b only selected branches and parents of changesets in these branches from another named branches (i.e merged branches) will be pushed to public, unfinished (and not merged) branches will stay local

Upvotes: 2

Related Questions