Hi everyone!
I would like to get your input on something. Basically, my client has a live version of their platform that consists of 3 apps (Frontend, Backend and API) that have separate Github repos. There is an urgent requirement to build a V2 of the service that will be using completely different data sources to process.
Because of urgency and to reduce the risk they proposed the following:
- Keep V1 as is
- Clone V1 into V2 and change the data sources and deploy it on separate AWS instances.
They want to Fork the repos to avoid risk, but eventually, want to merge V2 and V1 (so they want to remain eventually with just 3 repos as it is now, but every app would be able to accommodate both old/new data).
If we fork these we end up maintaining 6 repos and I can see a huge pain when trying to merge them back together eventually. Plus the code collaboration would become more complicated.
I am inclined to instead of forking create a v2 branch on each of repos.
The advantages that I see:
- easier to maintain
- increased visibility
- easier to merge in the end
Disadvantages:
- probably one big PR in the end on each of the apps
- merging v2 branch with the master on each of the repos has to happen simultaneously on all 3 apps (although feature flags could be used)
Note: All 3 apps are pretty complicated with big codebases and they work tightly together.
What are your thoughts?
Top comments (6)
If you isolate stuff in V2 in separate folder/package in same repo whatever you could potentially have seameless transition on the backend (api for me is a backend as well as backend you mentioned). Example let's say java, you have everything in packages and you just add 1 more to the root called v2, then inside you add new stuff. As for the routes may frameworks would allow you to add additional v2 in front easily regardless that 1st version is still there. Then you can later just refactor by removing v1 parts But keeping maybe v2 and just add later more version. You get the point. As for frontend I guess second repo must be there. However this way you could have 2 frontends targeting different routes and single backend code supporting 2 versions either deployed separatly or together. If you even decide to merge old v1 it should merge really easy as you have just additional folder/package on root level that should git or whatever merge easily no manual work requires. Ugly thing is if you have constraints that you can't play with UrLs
The issue is that because V2 needs to be a clone of V1 the namespacing bit won't work as this is an MVC framework and the number of files that would need to be moved in gigantic. And all 3 apps are the same.
MVC in C# ( beacuee you said namespace I'm assuming it's .net stuff) may be impossible-ish becaus of Project structure which is both better and worse than packages. In Java you can have easy way out but it depends on your current code base. I mean copying all stuff to root package v2 and just keeping up with the changes from v1 should be realy easy in Spring, Microaut, or so. But I understand, some tech-stack just have different style and you always hit the wall whatever you pick. Hope you find a good solution
Yeah, it's actually Rails not C#. But thanks for your suggestion!
In the 'seperate forks' case, would only the v2 fork be the one that's retained afterwards?
If so, then the branch approach's equivalent would be to afterwards not merge V2 into v1/master/main but just reassign V2 to be the master/main branch.
If not, then you'd need to merge the fork back into the v1 repos, which would be the same or (likely) more effort than in the case of branches, and in the meantime you lose a lot of convenience with regard to easy branch comparisons and patching v1 fixes to v2. And you'd similarly also need to do that at the same time for 3/6 repos, so nothing would be gained there.
Hi, Alain both V1 and V2 would be retained but they would want to eventually merge V2 into V1 and keep both versions under one codebase.