The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Branch and merge philosophy?

My team is in the process of improving our source control system, and especially our branching and merging system. Instead of trying to reinvent the wheel, I was wondering if there existed books/essays on the different "philosophies" related to those issues.

Quick overview of our process:

- We work on applications where reliability is essential. System tests can take weeks to complete because they're done by people skilled in the application domain, not us.

- We do a lot of parallel development on several related applications which share a common framework.

- We have a small team with good discipline, and we systematically do code reviews. "Breaking the build" is considered an unspeakable sin.

Any ideas?
BossyKena Send private email
Friday, August 18, 2006
 
 
As an answer to my own question, here's a first article that proposes one branching philosophy:
BossyKena Send private email
Friday, August 18, 2006
 
 
BossyKena Send private email
Friday, August 18, 2006
 
 
From our very own Eric Sink:  http://www.ericsink.com/scm/scm_branches.html
KC Send private email
Friday, August 18, 2006
 
 
What's your release cycle and feature size? None of the other stuff matters much.
son of parnas
Friday, August 18, 2006
 
 
Release cycle is roughly one major release every other month (with some maintenance releases to different applications in between). Typically, we have one or two people working on improving the core, a team working on a major application release (which might also involve changes to the core) and one poor victim doing the maintenance stuff on released applications.
BossyKena Send private email
Friday, August 18, 2006
 
 
"System tests can take weeks to complete because they're done by people skilled in the application domain, not us."

Separate your QA testing from your UAT (user acceptance).

Sit down with the folks doing the system tests and figure out how to automate them.

You mentioned reliability. You want to automate so you can thrash the code during the testing and see where it bleeds.
D in PHX Send private email
Friday, August 18, 2006
 
 
Agree with D in PHX. If you can't automate most of your tests then you can't improve your situation much. If reliability is key then automating is the only way you are going to be able to generate enough traffic in enough wierd combinations to actually provide a test. If you are just talking about GUI testing then you can still test most of the backend seperately.

I would:
1. have a separate branch per release.
2. don't have one person on maintenance programming. Every new request gets load balanced over the group in priority order.
3. create a broad set of tests that are smoke tests that you can perform in one day. A broad range of functionality should be tested to verify code is generally working.
4. Have someone run the smoke tests every 2 days on nightly builds.
5. Create a set of tests that take a week and have those tests run continually.
6. Release features weekly to support (5). Break the work down such that they can be done in 1 week increments.
7. Do development on the main branch rather than feature branches unless absolutely necessary.
8. Check-in code every night in a completed form. You can do it.
9. Have unit tests that are run in every build.
10. Branch for the release two weeks before the release date. Development continues on the mainline. Because you have been testing continually you should have a good feel for stability.
11. Bugs get merged as needed on the various branches.
son of parnas
Friday, August 18, 2006
 
 
Assuming that we do have a whole range of automatic tests that are run continuously (we do have this, part manual, part automatic, although there's always room for improvement obviously), we will still have to run sets of precision tests that can only be done manually by skilled domain-experts and which will certainly bring up unexpected issues. That's something we have to live with, unfortunately.

That leaves us with two options:

Option 1:
We wait until all tests are complete until we commit something to the trunk (the "the trunk should be releasable at all times, and nothing which is not 100% trustworthy should come close to it"), which basically happens only once we release an application.

Option 2:
We do commit semi-tested (as in, reviewed and tested automatically but which haven't gone through human tests) features and bug fixes to the trunk.

I'm leaning towards option 2 because option 1 seems like a merge nightmare. My team leader leans towards option #2 because having a pristine trunk at all times is an attractive idea. We'll see.
BossyKena Send private email
Friday, August 18, 2006
 
 
(Just to clarify, our system works with physically-based input which cannot be modelled with precision, hence the impossibility of automating everything.)
BossyKena Send private email
Friday, August 18, 2006
 
 
Then you must be able to replay different input sessions as tests?
son of parnas
Friday, August 18, 2006
 
 
In theory, we could (although designing a system that records hours worth of test and interfaces with the system is at least a one year project in itself. There have been failed attempts to do this in the past). But the main problem is that those tests take several weeks *to design* for each application (Don't ask me why; I'm not the domain expert :) ).
BossyKena Send private email
Friday, August 18, 2006
 
 
> In theory, we could (although designing a system
> that records hours worth of test and interfaces
> with the system is at least a one year project in itself.

No offense, but this seems like buck passing BS to me. The data comes and is fed into your program for processing. The data can be stored. Then it can be fed in.

How you didn't do this when developing the software would be the question I would ask as a customer.
son of parnas
Saturday, August 19, 2006
 
 
Take a deep breath, get yourself $50 and buy this book:

http://tinyurl.com/hpdhb

I read that in about two hours and has helped me more then anything I've read before.  Best $50 I ever spent.

... That SCM stuff can get mightly overwhelming if you think about it to much!
Cory R. King
Saturday, August 19, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz