views:

289

answers:

8

Let’s say you have four products each with their own release schedule. Each product has 50% shared code (common functionality across all products) and 50% product specific code.

Do you need a separate source control branch for each product? Should common functionalities always be developed in one of the four product branches and merged to the other products later?

Typical Scenario: Product A is being released next month and requires core (shared) enhancement 1, product B is being released in four months and requires core (shared) enhancement 2 (which will take three months to complete).

A: 

Put them all in one branch. You want to know at development time if a change in product A breaks product B. This is much better than getting into a merge mess when you discover that ProductB had to rewrite half of your common codebase your other 3 depend on as-is.

EDIT: To clarify, I mean they should all share a development branch. I would advise a separate Production branch to represent the code that is in production, and a Maintenance branch if you do regular bugfix releases.

Andy_Vulhop
I disagree: because doing that requires you to finish making changes to product A and product B before you can commit the single branch which includes the changes to both products. Instead, you might want to be able to commit/release one product before another is finished, which IMO implies having more than one branch.
ChrisW
The tradeoff there, then, is a much greater separation between your projects, which can (and historically, has) lead to a big ugly mess when you try to merge them.
Andy_Vulhop
+1  A: 

Not a direct answer to your question, because I'm not 100% sure there is a "one size fits all" answer that can be given. But Jeff wrote an excellent blog post around branching.

David M
Terry Lorber
+2  A: 

Common functionality can be developed in a separate Platform branch, with each product getting its own branch for the product-specific development.

Craig Martek
That doesn't answer the question, IMO: which is about whether, when, and how the various branches interact.
ChrisW
+3  A: 

I keep shared code in it's own product folder. Then use svn:externals to share the code amongst the other products. It's slightly painful to handle branching and merging, but it's better than having four copies of the shared code in the repository. Something like this (replace trunk with /branches/RB-1.0.0 or /tags/REL-1.0.0 for release branches and tagged releases):

/core/trunk
/product_a/trunk
  /core (svn:externals 'core /core/trunk')
/product_b/trunk
  /core (svn:externals 'core /core/trunk')
/product_c/trunk
  /core (svn:externals 'core /core/trunk')
/product_d/trunk
  /core (svn:externals 'core /core/trunk')

UPDATE0: Note that /product_a/tags/REL-1.0.0 might use /core/tags/REL-1.0.0 while /product_b/tags/REL-1.0.0 might use /core/tags/REL-1.1.0

Terry Lorber
But what if you are about to release one product, and check in a change to the shared code which breaks it?
Ben Breen
@Ben Breen - The release branch for Product A should use a release branch for the Core. Don't break the release branch. During that time Product B, C, D trunks will use the Core trunk until they are ready to release, and a new release branch for the to-be-lreeased product and the Core are made.
Terry Lorber
A: 

We have a similar scenario. We have common libraries for logging, data access and security but these libraries are used across multiple projects. What we do is create a separate set of branches for each product and then use SVN externals to link to the common libraries. So the common libraries are maintained in a "shared" branch across all projects, whilst all the projects themselves have independent branches.

This way we can ensure that all products are building against the latest version of the common libraries, whilst the projects are also able to maintained independently.

lomaxx
A: 

We built a series of sites that have a common base and a large amount of custom code using git by structuring it as a series of branches.

The master branch contained the core code, and each branch of that master was a specific customisation of the core. When making changes to the core, it was easy to push them down to the branches, while keeping each custom version isolated.

18 sites, and a 12+ month project with a team of 7, and it's still well under control!

Mr. Matt
Like it - this offers genuine code isolation. But why then put the core code in a seperate branch. Don't you want to see it in use somewhere, and hence have to develop it on a product?
Ben Breen
No - the core was not a production product - just the basis for the custom apps. This isn't a restriction of this method, just one of the project. There is no reason why you can't make the master branch a releasable product.
Mr. Matt
Actually I realised this doesnt work for us. We might get a requirement in product A being released this month which requires core functionality enhancement 1. Product B released in four months requires core functionality 2 (which will take three months to complete).
Ben Breen
This is where feature branches come in - each feature also gets it's own (temporary) branch, and the core and product branches only get the changes once they are complete. This means that there is never an instance where a developer breaks the build by half-finishing a feature.
Mr. Matt
Is a feature a 'User Story'? Or is there a difference?
Ben Breen
No difference, really. If I'm doing any unit of work, I always create a branch locally (i.e. not on the remote repo), and work in that. Once I'm happy it's complete, and working, I'll push those changes back into the master / product branch. This way, if I need to fix a bug that interrupts progress on my feature, I can just switch back to the product branch and do it, then pull the change into my feature branch and continue. At no time do I end up pushing half-finished work into the product branch.
Mr. Matt
+1  A: 

Here is IMO one of the best articles I've read about branching: Branching and merging in the face of agile development, extreme programming, team collaboration, and parallel releases

I think I'd want to avoid coupling the branches (and therefore the schedule) of two projects: and so, instead of a single branch in which you're editing common functionality and editing more than one product, perhaps one of the following two alternatives:

1) Develop the common functionality independently of any product

  • Branch common functionality
  • Add to it
  • Unit-test it
  • Commit it back into the mainline
  • Make product-specific branches of it (the mainline) and use it in products

2) Develop the common functionality with one product

  • Make a product branch
  • Within the product branch, add new functionality to the common library as well as to product-specific components
  • Unit-test it and system-test it and commit it back into the mainline
  • Make branches of the new mainline in which you use the newly-committed common functionality in other products
ChrisW
+1  A: 

Branch at the highest possible point in your tree. IE, it should include the code for all of your projects, shared modules...and probably things like documentation / build scripts / installers / etc as well. Why? Why not! Branches are cheap in all of the systems mentioned so far (SVN, TFS, Perforce, git).

This tactic is especially important in systems that use "path space" branching (TFS, Perforce). Otherwise, generating a build of the complete product suite that's consistent across different people's workspaces becomes a maintenance nightmare.

Once you've put this into practice, you're free to modify as much or as little of the codebase as you like in a given branch. You can always do a full build to verify integration issues; the option of merging any component(s) between any set of branches remains open to you. But the question of SDLC strategy is entirely orthogonal. You can branch per-feature, per-team, per-release or any combination of the above; you can define forward / reverse integration criteria however you like.* The fact that each branch happens to be a superset proves advantageous in many strategies, and should never be a con so long as your tools are up to the challenge.

*Picking a strategy is an individual matter that depends on lots of factors. Others have suggested some well known docs that help you decide. I'd put the most recent revision of Microsoft's TFS guidance up there with the best of them.

Richard Berg
Indeed. It would be great if someone could suggest a sensible strategy which meets the requirements. I always wondered if branching per feature is good practise or taking a concept to insane extremes.
Ben Breen
I sure agree with *where* you branch. The difficult question IMO is *when* you branch, how many branches, what types of change in each branch (i.e. the purpose of each branch), and how (e.g. in what sequence) to update and/ merge the branches/changes.
ChrisW
Ben: given what you've said so far, I would suggest a minimum of 1 branch per product. You want more if isolating dev vs test environments is desireable, or the teams are very large.
Richard Berg