CODEWITHSUNDEEP
user-interfacearchitectureuser-experience
vmodem
vmodem

Reputation: 13

Having one code base for multiple regions and clients

Context: We built a data-intensive app for US region for just one client using ASP.NET MVC and now we are slowly moving to ASP NET Core. we have a requirement to develop similar version for Canada, our approach was to maintain two different code bases even though the UI is 70% same.

Problem: Two code bases seems maintainable but were ending up doing double work if a generic component has to changed. Now we have multiple clients coming from multiple regions and UI can be a little different by client and region and we are bit confused on how to architect the such an app with just once code base.

I am not sure on what would be a maintainable and scalable approach. One approach is having an UI powered by rules engine that is capable of showing and hiding the components. How maintainable is this approach in deployments perspective?

what would be other approaches to solve this problem?

Upvotes: 1

Views: 1518

Answers (1)

Michal Ciesielski
Michal Ciesielski

Reputation: 336

The main approaches I can think of are:

  1. Separate code bases and release pipelines. This seems to be your current approach.

    • Pros:
      • independent releases - no surprises like releasing a change to Canada which the other team made for US
      • potentially simpler code base - less configuration, fewer "if (region == 'CANADA')..."
      • independent QA - it's much simpler to automate testing if you're just testing one environment
    • Cons:
      • effort duplication as you've already noticed

  2. One code base, changes configuration driven.

    • Pros:
      • making a change in one place
    • Cons:
      • higher chance on many devs working on the same code at the same time
      • you're likely to end up with horrible 'ifs'
      • separating release pipelines can be very tricky. If you have a change for Canada, you need to test everything for US - this can be a significant amount of effort depending on the level of QA automation and the complexity of your test scenarios. Also, do you release US just because someone in Canada wanted to change the button color to green? If you do then you waste time. If you don't then potentially untested changes pile up for the next US release.
      • if you have other regions coming, this code quickly becomes complex - many people just throw stuff in to make their region work and you end up with spaghetti code.

  3. Separate code bases using common, configurable modules. This could contain anything you decide is unlikely to differ across regions: Nuget packages with core logic, npm packages with javascript, front end styling, etc.

    • Pros:
      • if done right you can get the best of both worlds - separate release pipelines and separate (simple) region specific code
      • you can make a change to the common module and decide when/if to update each region to the newest version separately
    • Cons:
      • more infrastructure effort - you need a release pipeline per app and one per each package
      • debugging and understanding packaged code when used in an app is tricky
      • changing something in common module and testing it in your app is a pain - you have to go to the common repository, make a change, test it, create a PR, merge it, wait for the package to build and get released, upgrade in your app... and then you discover the change was wrong.

I've worked with such projects and there are always problems - if you make it super configurable it becomes unreadable and overengineered. If you make it separated you have to make changes in many places and maintaining things like unit tests in many places is a nightmare. Since you already started with approach 1 and since you mentioned other regions are coming, I'd suggest going with your current strategy and slowly abstracting common pieces to separate repos (moving towards 3rd approach). I think the most important piece that will make such changes easier is a decent level of test automation - both for your apps and for your common modules when you create them.

One piece of advice I can give you is to be pragmatic. Some level of duplication is fine, especially if the alternative is a complex rule engine that no one understands and no one wants to touch because it's used everywhere.

Upvotes: 1

Related Questions