0

We're planning Sitecore upgrade from 8.2 to 9.2 Azure PaaS using Sitecore Experience Cloud( XPScaled ) marketplace module. We'll be having 3 sites and due to business constraint, we can't proceed with multi-site feature because PROD deployment to any one site will impact other ones. So, the plan is one CM ( 3 publishing target for each site ) and 3 individual site specific CD.

Few queries

  • Should we separate each website code/assets by folder in VS solution OR create a completely separate VS solution for each website?
  • Is there any Sitecore feature which won't be available with this set up?
1

Should we separate each website code/assets by folder in VS solution OR create a completely separate VS solution for each website

It all depend on how much alike your 3 different sites are and how it is implemented. You can use a single Visual Studio Solution for all 3 sites but you need to bear in mind the development as it will affect each site.

For example, each site has a Top Banner component but they behave differently. So, you would need to implement the Top Banner in a way that it is shared across all 3 sites and the functionality should follow your requirement of each site.

Advantages

  • No duplication of code.
  • Reduce time to implementation

Drawbacks

  • Increase testing time.
  • Development brainstorming is required.
  • Difficult to manage.

If you have different Visual Studio Solution for each site, you can still have 1 Sitecore Instance with multiple targets to hold those sites. When deploying to the CM Instance, it will impact all sites but you'll be able to deploy to CD Instance without affecting other sites.

Advantages

  • Easy to manage the code as it will be different solution for each site.
  • No impact on live site because each site will be hosted on different CD Servers.
  • Different team can work on different site.

Drawbacks

  • Impact on CM Instance for all 3 sites.

  • When implementing a Custom Sitecore Processor / Pipeline, this may impact the site. Example, Site A requires a Rewrite Rule Feature while other sites doesn't. When you have deployed to CM, the rewrite rule processor will affect all sites.

  • You will need to have a proper deployment setup because each CD Instance will have different configs and code.

  • Developers should be aware of all the requirements, processors and pipelines of the sites in order not to cause regression when updating/implementing new capabilities.

Is there any Sitecore feature which won't be available with this set up

No. All Sitecore features will still be available as each CD Instance will have their own set configuration files and code. So, you can easily disable xDB for example on Site A and still works on the other 2 sites.

Sitecore xDB should still work. However, since you have different sites, in order for the xDB not to grow in size rapidly, you can use different connection string for the xDB.

So, for example, Site A will point to MongoDB Instance 1, Site B will point to MongoDB Instance 2.

In brief, it is up to the configuration that you are applying. For the CD Instances, you won't have any impact in terms of the features because each CD Instance will have their own set of configuration.

Now, if you have shared components, it is based on the development itself that is it should be implemented in a way that it caters for all the different sites.

Shared contents is also available. It is up to your content tree structure. In my opinion and experience, shared contents tend to be a repository which is at the root, that is, should be on the same content tree level as the sites. This make the shared contents easily accessible from the different sites.

HELIX PRINCIPLE

If you use the Helix Principle, you will mainly have a single Visual Studio Solution and then you can create you different Features. Code that will be shared can be abstracted into the Foundation Layer. With Helix Principle, it will allow you to decouple the features and it is easy to maintain. More information is available at Helix Principle.

  • Having different VS solution seems feasible due to ownership of each sites. Impact on single CM can be manageable but yes developers interaction is very important in either approach. Only drawbacks I can see in multi-instance set up is as mentioned in this post Yes we're using Helix principle as you mentioned we can think about single VS solution as well but again we need to restructure code in a way so that it shouldn't impact each site specific developers work. – Sukhjeevan Sep 30 at 5:05
  • For different VS solution we can create nuget package of common code base and reference in each VS solution in order to avoid code dependency. We're using Unicorn so we also need to sync .yml file as well for each sites. Single VS solution should looks like this post – Sukhjeevan Sep 30 at 5:08
  • Since our VS solution is on Helix principle so most probably we'll be going with single VS solution only along with 1 CM and 3 CD( individual for each website ) But in this case how reporting,processing will be associated with these 1 CM and 3 CD. Any issue? – Sukhjeevan Oct 2 at 5:24
  • We dug into further and decided to separate CM for each site as well but thinking it HTMLClearerCache feature will work or not – Sukhjeevan Oct 3 at 19:14
  • So on each CM you’ll have your publish end event which will trigger the cache html clear. You just need to specify your sitename in the config file – Hishaam Namooya Oct 3 at 19:37

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.