Question

I’m developing a web project that contains several modules (JSP, JS and CSS).

What’s the best approach from the SVN point of view when distributing the application for several clients in which each client will have access to a restrict number of modules and may customize the layout of each page.

Answer 1

Take it from a guy who has spent several decades in the swamps and trenches of Configuration Management:

DO NOT USE BRANCHING

Sorry for the shouting, but I want to warn you not to go there. Not to even think about going there. Branching means handling the branching, and it never happens. It becomes harder and harder to maintain, and it starts getting neglected. Let’s look at two different strategies:

Branching Per Customer

Oh, it sounds so simple. I’ll create a basic project, and mark the differences between clients on separate customer branches. If there’s a change for all customers, I’ll put it on the base branch and merge it to all the various customer branches. What could be simpler?

I’ve seen companies gone out of business because of this very strategy. They decide to create customized code for a client, so they branch for that client Then, a second client needs customized code, and they branch for that. Then a third. Now, it seems that a change for Client #1 is also required for Client #3. Well, we’ll merge that change from Client #1 to Client #3. Wait, Client #2 needs that change too. Okay, we’ll merge it to Client #2 too.

But, this feature is now in all of your clients, but not your base code. Your base code is completely out of sync with what your clients have. Some day, you’ll get those changes into that base code and update it, but you never do. Instead, it becomes a festering reminder that you’ve blown it.

Every five years, you should take your source code, put it through a shredder and start over. That’s because every five years, the entire software environment changes so much that your legacy code becomes a shackle that you’re dragging around. If you had a single project, it wouldn’t be too bad to start a new project. But, you now have six customers and six different projects. There’s no way you have the resources to pull everything together. You’ve written yourself into a virtual corner.

However, competitors will come by and they’ll have the latest and greatest code, and they will pluck your customers off one-by-one until they’re all gone and so is your job. I’ve seen it over and over. You must keep innovating, but it’s hard when you have customer specific code all over the place.

Keep a Core Code and Branch Only Specific Customer Stuff

Sounds easy, if you’ve never programmed in your life. A developer knows exactly what that means: You need to checkout from two or three separate projects and/or branches in order to do development. Some of those combinations will create neat and interesting errors that are hard to track down. You continuous build server will blossom with jobs for each possible combination. Code that was considered customer specific now is base, and must be moved (although that will probably never happen).

In the end, it’s simply impossible to keep straight. You’ll end up with code that should be client specific in your base and base code spread among your clients. It’s very much like the first scenario, but you’ve also added the fact that your build system is also hell.

---

So what should you do?

• First, use Maven. I am not a great fan of Maven, but there are many things it does.
  • Maven tells you exactly how to lay everything out. You put your source here, you put your JSPs here. No one can argue about it because Maven said so. You may disagree, but you can’t argue. Maven will make you put each jar or war as a separate sub-project with it’s own pom.xml to your project (which will have one pom.xml that ties everything together. That’s the correct way to handle this.
  • Maven has a built in way it handles dependencies. This isn’t just for third party jars, but for jars you produce that multiple projects use. Create a local Maven repository and use it.
  • Don’t know Maven? Learn it. Learn it as if your pay depends upon it because it does. Knowing Maven is probably worth about $20,000 per year for a Java developer. Yes, a developer who knows Maven can get paid a lot more — the difference between a Volkswagon Jetta and an Audi A6.
• Create a unified release and use configuration records to determine what a client should see. If a Client #1 needs feature “A”, and Client #2 needs feature “B”, you put both A and B in your code, and have a configuration record determine which feature which client sees. This has a purpose of making you think before you code too. It’s very easy to check out a client specific branch and hack away. But, you can’t do this if you have a dozen clients and you have a single code base. You start looking and seeing commonalities and maybe better ways of handling the situation. You end up with better code.
• There will be client specific code. In that case, make a directory for things like custom JSP screens. Try to keep this to a minimum, and use a Perl or Python script to help build client specific layouts. In fact, use a single centralized script, and come up with a configuration scheme to handle building the client differences. It’ll make it easier to see the differences.
• Make a single release for all clients, and setup your servers, so the client specific configuration isn’t overwritten by a new release. This makes releases much easier and less error prone.

90% of coding is in the initial design. The other 90% is in maintenance. Branches create more maintenance and encourage you not to worry about overall design. Don’t branch if you don’t have to.