CODEWITHSUNDEEP
mercurial
esther h
esther h

Reputation: 1468

Advice for setting up our development workflow for php web app and mercurial

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:

My idea for setting this up is...

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!!

Upvotes: 2

Views: 463

Answers (2)

Lazy Badger
Lazy Badger

Reputation: 97282

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

Upvotes: 2

Paul S
Paul S

Reputation: 7755

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.

Upvotes: 4

Related Questions