0

In our current project we are versioning software using gitflow as process and git/gitlab. We had some trouble managing multiple release at the same time, but nothing we couldn't survive.

Until now we had only client A and the project is very oriented to it. But client B will join soon. Also, we want to start to build a standard product out of client A's project.

So we are wondering how to organize our workflow and repository to manage both the product and the client's projects with all their customizations.

Our first idea is:

  1. turn the current project into the standard product (now this repo is client oriented, but we want to slowly turn it into the standard product)
  2. fork the product repo for client A
  3. fork the product repo for client B

On every one of this repositories use gitflow and take advatage of the gitlab's possibility to create merge requests between a repo and its forks.

But on the internet I didn't find anything like this, usually this kind of situation is handled with branches and parametrizations. So I'm starting to ask myself which can be the better solution.

2
  • Isn't client B's project simply another branch? Jul 5, 2019 at 18:50
  • Client B will also have multi release and lots of feature and bugfix. I'm afraid of making the repository too complicated to be handled if we add so many branches. Sometime I find it confusing even now.
    – k4ppa
    Jul 5, 2019 at 19:28

1 Answer 1

1

It's impossible to make this call without understanding the differences between Client A and B.

If A and B have identical needs that will always be identical it's silly to make two copies of the things that fulfill those needs.

If A and B have different needs that need to fulfilled by different things then sharing those things gets you nothing.

But, if like most times I've had to do this A and B have some needs in each category, the important thing is how well you feel you can predict which will be which.

If you can clearly identify what will be the same and used by both you can create a library with it's own repo for both clients to share.

If you can't clearly predict what will be the same it's best to ensure A and B know as little about what is fulfilling their needs as possible. This lets you pass in what they need. This can be done in one repository. Sometimes the only difference is the construction that happens in main(), usually if you use those parametrizations you were talking about to change what fulfills what.

Any way you do it, the important bit is that the people doing development have clear territory to work in. You've been very "client A" focused. You're organizing principle has been upended. You need a new one. Don't try to get back your single client focus. Look at the whole problem and organize around it. Separate what will need to change from what will stay the same. This might require reorganizing the team. But I caution against creating a client A team and a client B team. Everyone will just fall back into their single client focus and ignore the other teams problems. That only works if client A and B share practically nothing. Or if what they share is maintained in some 3rd repo.

Instead you can mark out the work that needs to be done do deal with any number of clients. You have spread the assumption that Client A was the only client around. Now it's time to go uproot that assumption and make the code as client agnostic as you can. Do that work before you even add Client B and adding it will be much easier.

It's easy to over engineer this kind of effort. Don't make wild assumptions about what Client C will be and try to fulfill it's needs before you know what they are. Increase the proportion of code you have that doesn't know or care which client you have.

Now something, somewhere is going to know and care which client is which. Separate that code. Use it to hide direct knowledge of the client from the rest of the code. Isolate it, keep it small, and new clients will force you to change less code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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