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?

closed as too broad by gnat, user40980, Robert Harvey, Bart van Ingen Schenau, ozz Oct 14 '13 at 10:38

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • What language is the product written in? – user1249 Mar 13 '11 at 16:56
  • the language is c/c++ – meeech Mar 13 '11 at 22:03

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.

  • You do not address his delivery problem. Have you trained your users to update every 6 months? – user1249 Mar 13 '11 at 16:59
  • They can subscribe to a special mailing list to get a notification when a build is available. Also within the application, they receive a notification when an official release is out. – user2567 Mar 13 '11 at 17:27
  • This is very similar to our process. Our heavy users spend most of their professional live using the code, and are always making suggestions, sometimes even submitting desired code patches for features thay consider critical. Some bug fixes, or feature enhancements we might only make available in the Beta, if the code change looks to be risky. Our application is highly techical with very sophisticated users. Other application areas could have quite different characteristics. – Omega Centauri Mar 13 '11 at 17:39

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).

  • thanks for the resources. WIll def check those two books out. Just having the term continous delivery will help me in my searches now :) – meeech Mar 13 '11 at 20:09
  • 1
    I think Software Product Line is the more important term to reference. I think that searching on that will help you find some free resources on implementing. – Michael Brown Mar 13 '11 at 20:35

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.