-2

Source Control

Here is a diagram of how our source control setup is configured.

The issue with this setup is how we handle various customers. I would really like to use a different approach than copying the entire baseline for each of our customers. I think further down the road this will become a major problem to maintain.

How can this be best achieved? Any help insight would be greatly appreciated.

Improve this question
7
  • Possible duplicate of Maintain hundreds of customized branches over master branch
    – 8bittree
    Apr 17, 2018 at 18:15
  • @8bittree I think the point is to avoid the repository per customer.
    – Frank Hileman
    Apr 20, 2018 at 1:32
  • @FrankHileman I'm a little confused by your comment. I was under the impression that it was the copying of the baseline for each customer that was the problem, not merely the existence of multiple repositories.
    – 8bittree
    Apr 20, 2018 at 2:47
  • 1
    @8bittree If you need to scale to thousands of customers, no one would use one repository per customer. One repository per customer sounds more like consulting services, where you have a small number of customers. Product development would do it differently, and would avoid customizing code per customer, instead using data that is different per customer.
    – Frank Hileman
    Apr 20, 2018 at 15:52
  • @FrankHileman I seem to be missing the part of the question that says that there are thousands of customers. Maybe that is the case, but it seems premature to assume that it must be the case. Either way, you can write an answer that addresses that. Secondly, "avoid customizing code per customer, instead using data that is different per customer" - sounds kind of like using config files, as recommended by several highly voted answers on the linked question.
    – 8bittree
    Apr 20, 2018 at 16:36

2 Answers 2

Reset to default
4

Some options:

  • Put only the customisations in separate repos and just copy them over the original repo when building the deployable. This is only feasible for superficial differences such as theming; once you have code patches in there it very quickly gets unmanageable.
  • Develop separately and merge changes which should be in both repos. This might seem like a good alternative until you have changes which you need to pull apart manually, line by line, to ensure that the repos each do what they want. This work just gets worse and worse with every merge, until inevitably the merges are too expensive to continue. Now everything is duplicate effort.
  • Make the customisations configurable, and put only the configuration in separate repos. This makes it much easier to handle code differences, since they are just feature toggles. The overhead of the switches is much more manageable than the other options unless they go completely out of control (and even then it's generally easier to just prune toggles than to do manual merges forever).
Improve this answer
5
  • 1
    As @l0b0 notes in each bullet, only the 3rd option is viable.The other two will quickly become unmanageable.
    – Tasos K.
    Apr 17, 2018 at 7:09
  • Thanks for your input, really good explaination. Worth mentioning, we as well have something called bundles where we gather artifacts from various locations and present them as package, which often is customer specific.
    – JonB
    Apr 17, 2018 at 14:28
  • That to me looks just like a snapshot of our baseline taken at some given time, and does not help with the maintenance of the code to my opinion.
    – JonB
    Apr 17, 2018 at 14:37
  • The third option is viable. I would not put configurations in separate repositories. I would simply add them to a backed up database or file system. If you want to support thousands of customers, you are unlikely to want thousands of repositories.
    – Frank Hileman
    Apr 20, 2018 at 1:32
  • @FrankHileman You could easily merge repos as branches if you end up in the enviable situation that managing all the configuration is a chore. But you definitely do want version history, which is cludgy at best in a database.
    – l0b0
    Apr 20, 2018 at 2:11
0

I would really like to use a different approach than copying the entire baseline for each of our customers

Copying? What do you mean?

If baseline, customer1 and customer2 are different repositories of the same codebase, then just add multiple remotes. For example if you need to work on customer1 code, clone customer1 and add baseline as another remote. Then you can just merge changes from baseline/master into your local product branch, and then push that on customer1/product1 branch. You may merge that back into baseline/master if you want to make some changes common to all your customers.

This way you only have one repo locally, sharing all the common references between your similar repositories.

Don't use customer1/master, as you may have several products for the same customer, so this won't scale, unless you want to store customizations common to all that customer's products.

Improve this answer
2
  • On a similar note, what about having more feature than customer requested for, so called “dormant feature”, is that a feasible approach under some circumstances ?
    – JonB
    Apr 20, 2018 at 20:27
  • If that's still a customer-specific feature, then that's just another branch on that customer repository, that you'll merge in time in the product it belongs to.
    – liberforce
    Apr 23, 2018 at 8:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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