1

I have got concerns raised by the 2 teams (to work in the same time) that multi site configuration may not be a solution for them. We want to have different sites working in the same instance of Sitecore.

For example: In the situation when we have multi site <site> configured (Let's assume SiteDefinition.config or Dynamic Sites Manager for Sitecore) and Web A has to use Membership provider "One" and Web B has to use Membership provider "Two" what is the best way to handle this situation?

And what is the other risk from having 2 teams working in 2 different web projects in the same Sitecore instance?

  • When you say different Membership Providers for Web A and Web B, do you mean separate authentication flow for the two public facing sites - that two separate teams are working on? Is it the same solution or there are two different solutions too - pointing to same Sitecore repository? – Hetal Dave Nov 8 '16 at 15:14
6

Working multiple teams in one Sitecore solution is a question of discipline and organisation. By organisation I primarily mean how and where assets for the sites are stored and organised.

To start with your example however; different sites needing different membership providers. You don't actually map sites directly to a provider, you map them to a default domain. Extranet by default, but this can be changed.

<site name="sitea" domain="domaina" ... />
<site name="siteb" domain="domainb" ... />

And each membership provider in your solution would be set up, to deliver these new domains to your solution.

As for how to organise yourselves; I recommend following the guidelines laid out in the Helix architecture recommendations. Specifically the section named Patterns, Principles and Conventions that directly discusses everything related to multi-tenant implementations, file structure, organising Sitecore content, security setup and so on.

Helix Recommendations

In short. Yes, there are some more things to consider when working multiple teams in the same solution, but it is definitely doable and done by many teams around the world every day.

Breaking up your solution into two separate Sitecore instances has the added implication of needing a whole new set of licenses. One set for each site. Depending on your customer, this might not be an option at all.

  • Thank you so Much Mark. I believed it is doable so. Thanks again for the principal link. There are a lot of resistance (fear) from the development team which I can appreciate from them. Hopefully I will have a success story to share in 2017 after the projects go live. – Atit J Nov 9 '16 at 15:19
2

As Mark said it's completely possible, but there are a number of aspects Top Sitecore development that can cause issues if the disciplines is not strictly enforced.

For one, there's many "shared" components that people like to modify, think about DI, rendering pipelines, Link Manager, error pages, etc. Then there's the dependent assemblies, remember that both code bases will be listed into a single appdomain so it's necessary to carefully manage the versions of libraries like Facebook, NewtosoftJson, MVC, and so on.

Also, while most areas and functions can be divided into folders to allow separation between the teams, there are some areas around personalisation and reporting where that doesn't apply, so you need to manually manage security in this area. We have a Content Editor Warning that prevents editing items that weren't created by someone in the same group as you, then we have role groups for each agency. These can be applied to various sections of the site.

Lastly be careful with aliases, since they apply across domains.

Hth

  • Thank you Richard for pointing out the common areas. What is the first approach come to your mind to avoid each team to step on each other toes in those areas? E.g. naming conventions? – Atit J Nov 9 '16 at 15:23
  • @AtitJ We use subfolders and permissions where possible, and Content Editor Warnings where not; you will definitely need a governance team - something like a pull request for any config changes. All global systems are wired in through the config system so monitoring changes to the configs will tip you off when someone is being naughty. Don't forget to brief the dev teams on what is expected of them. Catching an issue at "pull request" time is often a bit late, as the soln is already coded, so get involved in the design phases to ensure that architecture is conforming before dev begins. – Richard Hauer Nov 9 '16 at 23:47

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.