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.
