2

I am setting up our (relatively small) programming team to work with source control. Until now, there has been no control and things have been... haphazard.

The team is comprised of 6 developers, 2 of which are also the QA people. I've been doing lots of googling the subject and it's overwhelming! So far, the only decision I've made is that we'll be using mercurial.

Background: This is a web application, developed in PHP. Constant development of new features (which means equally constant fixing of bugs :-P ) We started out by outsourcing all the web development, which means that our production code is hosted by another company. So we can use Mercurial to develop and test in our internal network, but when it's ready to go live, we'll need to ftp the files over to yonder company. (silly? that's the way it is... they also do seo and other work for us, so management is not about to part with them).

Here are the requirements for the workflow:

  • Multiple programmers may be developing new features together, or separately.
  • At the same time, the programmer may be called away to fix a bug, then get back to whatever feature he was developing
  • If a bug was fixed, we want a QA person to test, and then get it to production ASAP
  • If it's a new feature, it can go to a test environment where QA will thoroughly test and then it can get shipped.

My idea for setting this up is...

  • each programmer has his own repository
  • there is a central dev repo
  • there is a QA repo

So, a programmer wants to start work on a new feature. he creates a brach, does his work, he's happy, merges with his main branch. Now he pulls changes from dev, merges, pushes to dev.

QA person will pull from dev to the QA repo. Since many people can be pushing to dev, and we want to focus on testing one new feature at a time, MrQA can choose which changesets to apply (or whatever the terminology is). tests the feature - works! ftp to production. Then can start testing the next feature from dev.

For bugs - a programmer will make the fix in his local repository, send directly to QA, and then from QA it goes live.

But... what if we have two QA people testing in the QA repo at the same time (testing two new features)? the ftp transfer will send all files... so that means all features there need to be ready to go, and we'll need to wait for both of them to be done. Which is part of our current problem, waiting for things to be tested from other developers before my own fix can go live... which is why we wanted source control... so now I am confused!

Ok, now I need some advice. I read up on having separate branches for each revision. separate branches for each shipped version. I really don't know what to think... is the workflow described above usable? Is it overkill for our small team? Or, is it too simplified? Since I am the one selling everyone on the version control thing, I don't want to set something up that will flop after a week...

Thanks in advance for coming to the rescue!!

Improve this question

2 Answers 2

Reset to default
4

First of all congratulations on making the decision to have some kind of version control. There may be some pain early on, but it'll be worth it in the long run.

My initial thoughts are that the dev side of things sounds fine. I'm not convinced about the need for a central server, but many use it without problems.

I think the issues start to creep in around QA. You say:

QA person will pull from dev to the QA repo. Since many people can be pushing to dev, and we want to focus on testing one new feature at a time, MrQA can choose which changesets to apply

This means that the QA guy is cherry-picking from the dev tree, so I assume he'd be using something like graft. In which case QA have a branch that doesn't exist anywhere in the dev ecosystem. When a developer needs to fix a bug, will he fix it in his dev tree, or off the QA branch? If he's fixing it on the QA branch (that's where the bug was) how does it get back to dev? I can see problems here where dev and QA are forever diverging.

Personally I'd recommend reading how the mercurial project does it. Basically there's a named branch for each release that QA will be testing. Any bugfixes for QA go on that branch, and it can be merged back into development branches. No cherry-picking as part of the normal flow, as I'd expect it would get difficult to manage in the long term.

There are other work-flows out there (probably as many as there are people using mercurial ;-) ), but this is a good starting point, and you can tweak it as necessary.

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

4 Comments

maybe i'm just not getting how mercurial is meant to work... how would it go without a central server? we need all programmer's work to get tested by QA people before being sent to production. so how would you do it? I followed your link to mercurial's project, but I just can't understand how it would work in our case... please explain. thanks!
pull-only and pure p2p exchange of changes can work - every Mercurial have hg serve (it's fastest, but not single way to share repo), which will show repo to public
The link doesn't really concern itself with central or not. To be honest, I'd say that was a bit of a distraction for a team this size. Go with central server if that's less alien. The important thing in that link is how the branches are structured. A named branch for the release to QA which gets bugfixes. Those are then merged onto the dev branch (default). hginit.com is also worth a read. It really starts from the basics, but finishes up with talking about branching for releases, QA, etc. It's not very long either.
@PaulS thanks for the help. i did read hginit at the beginning of my research, which is where i got the idea of a central server from.
2

Follow-up to Paul's notes

  • For 6-members team I also think you can use or not "Cental Server": in sipliest form team can p2p-pulls, when needed and some sort of central server will appear automagically as (possible - one of) repo some of QA-persons
  • Think "on the shore" (read Steve Losh for starting-point) of which branch model you choose and will follow in the process (named branches /exneded and expaned to "git-workflow"?/, separate repos)
  • Partial repo on QA-side can become a source of additional troubles (see Paul's text again). Maybe full clone and strong communication (team is small) "Test branch X against default" will be more clean way

what if we have two QA people testing in the QA repo at the same time (testing two new features)?

Everybody have own repo (they may be identical, but QA-tests used for different branches). Maybe here will be place of Central QA-repo, in which only QAs can commit passed all tests changesets and post-commit hook publish every change to external 3-rd party

I read up on having separate branches for each revision. separate branches for each shipped version

I hope, it was "branch per feature|branch per bugfix|branch per mayor-minor release", not branch per changeset

Final conclusions (just IMHO)

is the workflow described above usable?

Yes, it may get some modification diring real-life, but it's a natural process

Is it overkill for our small team?

I don'think so - it's logical, semi-transparent (QA-part only seems to be polished somehow) and well-scalable to wide teams (while "chaotic anarchy" communication may be replaced by some more hierarchical model at some time)

is it too simplified?

Can't see over-simplicity here

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.