We use a fairly typical/recommended workflow with 3 separate repositories (dev, qa, and stable). This only works "ok" for us and I'm looking for something better.
Our project is a web application with a weekly release cycle. Every Friday we promote dev to qa, and qa to stable. We then deploy the stable code to the hosting environment over the weekend.
We have a couple problems with this. Both related to the basically all or nothing promotion of changesets between repositories that arises from the fact that changesets depend on their parents.
- There is a certain type of artifact in our project that has a MUCH longer QA cycle. They have to be approved by folks outside of our development organisation. Sometimes it can take months for these to be approved. These can't be in our main dev/qa/stable repos because they block our weekly releases.
Our current solution is to keep these assets in a totally different set of dev/qa/stable repos and have scripts copy them into our main source tree from the appropriate location. This unblocks promoting our main repository, but it is very clunky. And we still can't promote each asset individually. Per-asset promotion seems like it would require separate dev/qa/stable repos for EACH asset and there's nearly 200 of them. 200 assets * 3 repos for dev/qa/stable comes to 600 repositories! That doesn't seem like the best idea.
- Sometimes features take longer than a week to develop, and we don't want those changes being promoted to QA before they're ready. We can usually deal with this by using a feature branch repository and only merging it into dev when it's done. The problem with that is we don't get to see work in progress show up on our continuous integration website. Not until it is merged into dev anyway.
Does anyone have ideas on how to do this better? Surely I'm not the only one that has ran into these problems before.
We are not currently using subrepos or named branches. Would they help?
