How do you manage frequent software releases to multiple clients?

Question

we have a cross-platform middleware product which we typically end up customizing/bug fixing on a per client basis. In some cases, providing updates as often as once/twice per week.

We have a lot of trouble efficiently managing and releasing the updates to our clients.

I've done some digging, but I can't find anything to specifically address this problem.

Can anyone share their experiences - how do you deal with this scenario, or do you know of a good software delivery cms?

Answer 1

Here is what we do:

• We have fixed iteration in which we build all the planned features.
• Each time a feature is completed we trigger the automated build script and we make it immediately available in a special area called "BETA". It's fully automatic including web page update & upload. It's called BETA because it is a term well understood by our users. But it's purely development builds. Ready to be consumed by them. The fact it's a BETA page, the user accepts imperfections and the fact they become implicitly tester of that build.
• At the end of an iteration, we decide to do an official release (newsletter, website change, etc) or delay to the next iteration.
• During the process, we receive feedback from our customers continuously. Sometimes, we address a feature immediately. We made it available very quickly trough those dev builds.
• If we face an annoying bug, we fix it on the trunk and merge it to the branch we did when we released the previous version. And update the file in the official download area silently and notify the users that have been affected by the issue.

Doing so give us the following advantages:

• We control our release process. Our customer feel it and then trust us more.
• Some customers are more eager to provide valuable feedback as they see it matters to us. Many innovations come from that channel.
• Our customers know that we are continuously building on top of what they paid for, and therefore have the (real) feeling it worth the money they invested in it.

That's just an overview of the process, but I'm sure you get the point.

Answer 2

For the most part, I use branches. On several rare occasions, I clone an entirely new client specific copy of the repository. The main point being, you want everything to stay 'related' so that merging and perhaps even cherry picking doesn't have to proverbially suck.

I follow the same rule that I follow when making a fork of any other open source project. If I need the project to go in a direction that most people involved would consider overly localized and specific to my own needs, I fork it. If the client's needs are digressing enough from the main effort, fork off another repository.

Otherwise, it is not at all uncommon to maintain branches for various architectures, so branches for particular clients that don't require you to deviate too far from the main development focus would serve basically the same thing.

Then again, there's nothing wrong with cloning one new repository per client. The point is, keep them all related so that your version control system helps you manage merges, bisections, tags and all of the other lovely things that we count on them to do.

Answer 3

There's a great book called Continuous Delivery that might help you. Also, you might want to look at a process called Software Product Lines which addresses approaches to maintaining a group of closely related software branches. We used that technique when I was at Convergys (which handles billing for the majority of the Wireless and Internet service providers in America using a single product that is customized for each of the providers).