Git management technique when there are multiple customers and need multiple customization?

+15 votes

Git management technique when there are multiple customers and need multiple customization

Mar 26, 2018 in DevOps & Agile by Atul
• 10,240 points

2 answers to this question.

+2 votes

Consider this - In 'extended' Git-Flow, (Git-Multi-Flow, sounds catchy, anyone?), every developer working for customer XYZ configures, for example:

  • name of target core master branch: master-XYZ
  • name of target next-release integration branch: develop-XYZ
  • naming scheme for feature branches: feature/*
  • naming scheme for release branches: release/*

I've planned them to use DIFFERENT names for master/develop branches. That means that for each customer, I have separate next-release integration branch, and a different version of the current-release branch.

What does it give? Any developer that works on a feature (be it patch, customization, whatever) just uses git flow. But if they work in context of customer XYZ they will 'finish' the feature and it will be integrated on a dedicated develop-XYZ branch. When released, it will get merged into dedicated master-XYZ branch. No possibility of "leaking" features or customizations.

However, 'feature' branches are still normal. If at some point of time you want feature #100 (originally for customer ABC) and bugfix #321 (orig for customer DEF) you can still merge them to another customer like XYZ, provided that the differences in their relevant develop-?/master-? are not too different, but that's another story)

It's not that great actually. With decent amount of customers and separate devel/master for them, you will quickly notice that:

  • if customers' customization are hard, they will diverge their develop/master often, not only in customized areas, but in the core code as well. That will impeded future feature sharing between them
  • developers will get grumpy about having to change git-flow configuration constantly (swithc to master-FOO, switch to master-BAR, master-XYZ), or, having to keep several repo copies, configured to different customers
  • having separate develop/master is almost like having separate repos, but change notifications will spam everyone
  • (..)

That's for starters. Some of them can be mitigated. The second point can be solved by noticing that git-flow setup just a few lines in the .git/config file, so you don't need to re-config gitflow or keep several copies of the repo. Just edit the file. Or keep a copy of git-config and just flip that file. Or use some $ENV var to indicate current customer. Tenths of other ways to solve it.

Next thing, features. I deliberately didn't consider naming feature branches feature/XYZ/ but left simple feature/. Features don't have to be bound to customer. You can share/etc them later.

Next thing, releases. I deliberately didn't consider naming release branches release/XYZ/. You will not share them, ever, probably. You may. However, I suppose you already have a better naming for release branches than just prefixing them with customer name like releases/XYZ would do. You need to version number or date there as well. Maybe some feature set code name as well. I don't know. Invent something here.

Next thing, core master and develop. For customers, devs are working on develop-XYZ, master-XYZ. But you can still have core master and develop for working on improvements of the shared core code. No changes there.

Next thing, I said master-XYZ, develop-XYZ. But that does not have to be like that. You know about feature/.... So why not masters/XYZ & develops/XYZ? Sure, can do. You can even XYZ\masterand XYZ\develop and XYZ\feature\ but then, why not make separate repos like on GitHub, where you can Fork/Merge/PR one off another?

Git-Multi-Flow is an extension of vanilla Git-Flow, and with the latter naming scheme (XYZ\masteretc) you end up with something like multiple logical repos in a single repo. Kind of multi-tenant Git-Flow..

So.. It's possible. Not that hard to set up. But still 1000+ branched master/develop/etc sets, handled by the same group of teams will be a pain. There will be mistakes. Devs will mix up things from time to time, they're just people. From my experience, when "lots of customizations" happen, it's almost just URLs, ports, passwords, images, styles, text, maybe sometimes limited layout changes. Maybe one extra module here or there. You should be able to handle it all in core code, and turn it on/off/configure via configuration. This way the number of long-lived 'customization branches' (aka master-XYZ) will be greatly reduced, at the cost of more detailed configuration for each customer deployment.

That configuration should also be tracked and versioned (i.e again in Git). I hope you do it already. But it should sit in a different storage than code. It's a different thing. Managed by support or deployment team. 

answered Mar 26, 2018 by DragonLord999
• 8,450 points
0 votes
You can use multiple repositories for this which in turns requires application to be built in such a way that it has stuff common with all the users.For each customer create specific module with customization, each of then go into separate repositories. If a client requests a feature that requires customer-specific changes to a core module, refactor your application so that the customization can be done outside the core module. If time is an issue, use a client-specific branch and do cherry-picking or merging. This is alright as long as it is for a short period of time. We successfully use this approach at one of my clients, who has exactly the same challenge.
answered Jul 27, 2018 by Kalgi
• 51,970 points

Related Questions In DevOps & Agile

0 votes
1 answer

Is there any difference between jenkins ssh publishers and ansible?

In a Layman’s language they're the same ...READ MORE

answered Apr 9, 2018 in DevOps & Agile by shubham
• 6,910 points
0 votes
1 answer
0 votes
1 answer
+5 votes
2 answers

How to program and get the Digital Ocean ID of the current Droplet from within the Droplet?

You can run curl within the ...READ MORE

answered Mar 26, 2018 in DevOps & Agile by Atul
• 10,240 points
0 votes
1 answer

How do I use Devops with Xamarin and hockeyapp

It would be better if you use ...READ MORE

answered Mar 26, 2018 in DevOps & Agile by Atul
• 10,240 points
+5 votes
2 answers

Xamarin and hockeyapp for DevOps

You can use Jenkins instead, It has ...READ MORE

answered Mar 27, 2018 in DevOps & Agile by DareDev
• 6,870 points

edited Oct 12, 2018 by Kalgi 180 views
+2 votes
1 answer
+2 votes
1 answer

Deploy Docker Containers from Docker Cloud

To solve this problem, I followed advice ...READ MORE

answered Sep 3, 2018 in AWS by Priyaj
• 57,700 points