How do others handle product branding in source files?

Share URL
 
jlm's picture
jlm asked on January 11, 2011 - 4:27pm | Replies (5).

For my product, we have 1000's of source files but only a dozen or so need to be customized to brand the product.

Right now I keep copies of those files for each customer. I merge base product changes into the branded files as part of the branding process and I overlay the base product files with the branded files as part of the build process.

Is there a better way?

Jeremy Mordkoff

Tags: 
configuration management

5 Answers

TechWell Contributor's picture

It sounds like you have some code files that might get changed along with all the other code files, but these particular code files also change -- from your end -- for the branding process.

If possible, it would be wise to move all brand-related items/strings/graphic-paths out of your files and into their own subset of new files, or even a database (similar to the process of abstracting strings for localization purposes). I realize that developer effort may be required to do this. For example, if one of your code files has a path string that points to a graphic, and the string changes depending on the client, instead make the string always point to one resource that the developer never messes with and which you swap as you see fit.

The goal would be to entirely separate the code (which the developers can change) from the branding (which you are apparently in charge of). Then the developers can change code all they want, and the only thing you need to keep on top of is new, brand-able resources and making sure that the correct brand is included every time you put together a release.

jlm's picture
jlm replied on January 13, 2011 - 5:50pm.

I've already done most of that.

For instance, we have a strings file. Developers are adding to this strings file for each release. They use techie speak in their version.

I have a copy of this strings file for each customer. They rewrite these strings as they see fit. Then as part of my build process, I overlay the original version of this file with the customer's version and run a build. pretty simple.

But now we're on the next release and there are new strings to be customized. How do I get the new strings into the customers' file so they can rework them?

I could merge the changes made to the base file into the customized file. That would be messy unless I had fenceposts of static text that the merge process could lock onto to figure out which strings had changed. I think I solved this by splitting the strings across two lines. The first line holds the label and the second line is the string and since the labels never change, this seems to work okay.

So, should I create a branch for each customer and keep their customizations in a branch? That would allow me to use the standard build tools, but I would have to merge their changes from a branch based on release 1 to a branch based on release 2. Then patches could be done by simply merging from base rel 2 branch to the customized rel 2 branches.

Or should I stick with my copy methodology?

to put this another way, should base product changes merge to customization branches or should the customizations be applied to the base branches. I suppose the answer may depend on whether or not I could ever conceive of releasing a customized build without the latest changes. That would be most easily done using the merge from base to custom method.

I was kind of hoping someone had some tools to help with this.

Joe Farah's picture
Joe Farah replied on January 17, 2011 - 5:30pm.

You may want to consider a run-time overlay. Always include the base file, and optionally the customer file. When the string is referenced, look first in the customer file, if present, for it, and if not there, then take the base value. In this way, you never have to do any merging.

On top of this, you may even wish to export support of the customer file to the customer so that they have ownership. This may require a bit of a design change but my experience shows that this would be minimal and would ultimately give the customer more control, and flexibility (e.g. they could correct a string on the fly instead of waiting for the next delivery).

Cheers,
Joe

TechWell Contributor's picture

jlm --

If the strings file is the only thing that changes between customers, I wouldn't recommend separate customer branches. As I've thought through the problem, I think the following might be useful to you:

As you move forward on your mainline, branch off for each release, letting that branch become a maintenance branch. These are customer-agnostic.

Keep your strings files together in a place in the repository, but in their own folder. Of course, whenever a branch is made, this folder is branched with the rest of the codebase, so you have strings files that stay pertinent for that release. However, as the developers continue on to new releases, the strings files in the mainline will morph and evolve as you and the developers add/delete strings and customers.

Whenever you do a release, whether it be from the Head or from some branch, your release process can include whichever strings file corresponds to whichever customer you're releasing for, copying the file from the container folder.

One of the keys is that whatever strings files are on Head of the mainline are the very freshest and only reflect your latest version.

If you are using Subversion as your repository, for example, the developers can easily check out the customer strings folder and edit it.

jlm's picture
jlm replied on January 18, 2011 - 11:46am.

That's pretty much the path I've taken. I have some code changes, but it's mostly strings and icons, which they can tweak.

My question is really more about how to use source control to manage the customizations. The customers' changes are in branch rel_1 which has been merged to trunk. Now we branch rel_2 from trunk. Then the customer asks for a tweak to rel_1. How does that tweak get into rel_2? I'm trying to keep things simple, so that normal merge rules will manage it for me.

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.