-1

I have asked this question on Stack Overflow and I got a suggestion of posting it here for better suitability. So here is my question :

I am new to DevOps, and i have a solution with Umbraco as CMS, Mobile App as front-end for the content added in CMS and .Net MVC web API to connect CMS with the Mobile App. I also have WebJobs and Microsoft flow for some scheduling tasks.

I need to implement DevOps for my Multi Tenant Application, here is my scenario:

The solution will have one master application which will just serve as master list of features for admin to enable features while creating new community. Multiple communities having separate databases, each community has multiple features (Feature1, Feature2). There should be a way for developers to forward integrate and backward integrate the features.

After adding the feature to any community, It can have its own customizations in particular feature. In some scenarios developers also need to add these changes to the master or the sibling communities. I also have added the Image for better understanding.

Architecture Image

I need help in creating the Branching Strategy for my solution that fulfils all above requirements and minimize the chances of conflicts while merging the branches all across. I have below options in my mind.

  1. Should I consider each Feature as separate branch? If yes, how about managing the community specific changes done in any single community?
  2. Should I consider each community as separate branch? If yes, how do I separate out the feature code to be merged with the community branch?
  3. Should I consider shared code among all the communities? If yes, what about the community specific changes?

Everything is going to be on the fly once deployed (in code base using Visual Studio 2017). Which strategy I should go for? Or there is any better approach than these? How can i manage to resolve the merge conflicts if generated after the deployment? Also, in DevOps Should i go for Git or TFS?

0

Keep it simple for yourself. Just put all "communities" in a single branch.

In most development methodologies, feature branches are created to isolate the development of a feature; once the feature is completed, it should be merged to the master branch, and they become part of the base application. Feature branches isn't intended to isolate different configurations of an application.

Add feature flags to the application, use strategy patterns to provide different behaviour for different configurations.

This way, you don't need to rebuild applications multiple times for each community, everyone uses the same exact executables, with the differences described in high level in a set of configuration files.

If your community configuration is complex, you may want to version the configuration files as well, but these configuration files should be versioned in a separate repository than the base application. You probably want to create one repository for each "community", or alternatively they could be different git roots in the same repository, you're unlikely to need to want to share configurations between "communities", so you might want to avoid merging between different community roots. Another alternative is to create a single-family branch with all communities as folders, this should be done with caution, as it may be difficult to split the configurations for a single "community" without losing git history, as their histories will be intertwined with other "communities".

  • Thanks for the reply. As I am new to all this, can you please give some more understanding on this? As I read that the feature flags lead to Technical Debt. Is it more suitable to my approach? any reference will be appreciated. – Developer Dec 21 '18 at 12:58
  • @Developer: Feature flags don't necessarily lead to technical debts if you're using all the features, just in different places. It only becomes a problem if you have flash that are essentially always in a single configuration, or if you use it as an excuse to not upgrade everyone with features that really everyone should have. In fact what you described you're trying to do with feature branches is really just a convoluted way to do feature flag, one that's just quite impractical and going to cause you a lot more problems than just doing it properly. – Lie Ryan Dec 21 '18 at 13:53
  • @Developer: Also, you're confusing two different types of feature flags. There are feature flags that are used to do partial deployments of new features, these are the sort that should be short lived, they should be removed once developers believe the feature is ready and you're committed to the long term support of the feature. But there are also feature flags that are part of the business rules, these are usually a permanent fixture on the software. – Lie Ryan Dec 21 '18 at 13:58
  • Thank you very much for explanation. It is helping me a lot. Let me know if "Business Flags" are is still applicable if my multiple tenant's has : 1. The tenant will not share the content expect some configuration 2. The tenant might have some extension to the base feature,i.e. some functions added/removed or twicked form a feature. 3. My solution is micro-service based architecture 4. The Data security measures are different per tenant 5. May be the deployment mode/environment is different, like some on cloud or on premise etc – Developer Dec 24 '18 at 9:16

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.