tags:

views:

161

answers:

4

I'm working on a very large project with three phases of source code.

  • Development source code: changes rapidly every second, and checked by our QA
  • Test environment code: released to clients' QA department (released every 2-3 weeks)
  • Production environment: after confirmed ok by client QA its released to prod. (every few months)

The system (governmental web app) is very large to track changes,bugs and hot fixes, sometimes the Testers could ask for a change, some other times the Production could ask for a hot fix or small update.

The problem is, when the Test or Production request changes, the development code is already changed a lot, and they always warn us they want only that small fix, do not upload anything new with it.

The question, how should i manage the code for the 3 phases, and get back to Test or Production code any tie and fix that small one thing (reflecting the change to the current Development as well)?

Note: making a branch each time is too much, and i don't want the developers to be lost between updating the mainstream, the branch and the Test code!

+1  A: 

Instead of branching the trunk for every request (which would include new code not related to the quickchange or fix) what if you branch from your prod tag and made the change then test, qa and redeploy that.

Steve Robillard
+1 exactly. When people want a small fix to a well-tested system, they want to get only that small fix, and no other changes (that the devs happen to have made in the mean time). Otherwise, impact assessment and re-testing would be too expensive.
Thilo
+4  A: 

Checkout from the particular revision that was supplied to Test or Production and merge changes later back to dev.

Padmarag
just don't forget to merge them. Better merge them as soon as QA has signed off on them.
Thilo
+1  A: 

Making a branch each time is too much, and i don't want the developers to be lost between updating the mainstream, the branch and the Test code!

Branching from the trunk for each and every patch is unnecessary (and it won't do what your test/prod teams need). However, you cannot entirely avoid branching, and you cannot avoid your staff having to work in multiple branches.

You should be able to keep the number of active branches down to (say) one for the version running in production, and one for the version that the testers are working on.

Stephen C
+2  A: 

Actually I think you should have your three branches * development (trunk) * QA * PROD

The merging is "quite easy" (as easy merging can be) as you always have to merge from QA to DEV and from PROD to DEV. This is quite a common setup which we use in many projects.

Edit: Normally you do not branch again on QA nor PROD.

GandalfIX