Simple mercurial webdev repo setup: features vs. fixes -


i have inherited mercurial system basic web site, i’m new mercurial , temporary site babysitter until find lot more competent me. in meanwhile, use pointers on how can keep our feature development separate quick bug fixes.

currently, have 3 basic environments: individual developer environments, staging, , production. each environment has own local mercurial repo. single bitbucket repo acts master repo every environment pushes , pulls from.

the problem when working on code unfinished needs submit quick bug fix needs deployed quickly. if developer has committed changes unfinished code , commits quick bug fix , push, code goes bitbucket repo.

judging i’ve researched far, can development bitbucket repo (for slower development) , “stable” bitbucket repo (for fixes need happen now)

in situation, on our dev machines, we’d of our slower dev code in our local dev repo cloned local stable repo. when wanted share unfinished code, we’d push/pull bitbucket dev. other developers push/pull local dev bitbucket dev keep local dev environments in sync or merge code.

when we’re ready push production, we’d push code our dev environment bitbucket main , pull staging testing. if looked good, we’d pull bitbucket main repo production. later, we’d pull bitbucket main repo our personal stable repos keep them in sync , pull personal main repo personal dev repo in sync.

if we’re in middle of incomplete code in our dev environments have make bug fixes quickly. we’d bugfix in our personal stable repos should free of incomplete code, push local repo bitbucket stable, , pull production. we’d pull bitbucket stable our personal dev environments keep in sync production still preserving our unfinished code.

it feels there’s simpler way of doing i’m not understanding. advice appreciated.

the problem when working on code unfinished needs submit quick bug fix needs deployed quickly.

this question of used workflow , (missing) management, sorry. see @ least 3 weak points in current state

  • (unrelated) why 3 repos instead of single repo special named branches?
  • why, switching task workstyle, mq extension not used mandatory tool?
  • why development happens in default branch , named branches not used?

i, pm in situation evaluate 2 possible ways , implement after testing of (or combination of both)

  • mq extension single-branch mode must used any wip. finished , tested changes can converted changeset(s) (and, thus, can pushed public)
  • single-branch mode replaced "branch per task" workflow (any task - new named branch in developer's repo, merged later default) , default push-mode "all branches" replaced "push specified branches": ...-b default in case of separated repos, -b default -b staging -b prod in case of single repo separate branches per target /devel, staging, prod/. in case of -b selected branches , parents of changesets in these branches named branches (i.e merged branches) pushed public, unfinished (and not merged) branches stay local

Comments

Popular posts from this blog

SPSS keyboard combination alters encoding -

Add new record to the table by click on the button in Microsoft Access -

javascript - jQuery .height() return 0 when visible but non-0 when hidden -