RFC: Multiple Deployment Targets

[nickwesselman]

As Sitecore XP continues to introduce independent services split off from the "monolith," there is an increasing need to be able to deploy to multiple targets, both locally and in test/production. This includes Sitecore Commerce, XConnect / Marketing Automation, and the new Identity Service. Helix should include recommended practices for solution structure and deployment to these multiple targets.

The Commerce Pull Request from @robearlam provides some foundation for this when using VS Projects to define module boundaries. How would this be handled in alternate solution structures (#21), such as project-per-layer?

[lakesol]

I agree this needs to be address soon. At the moment lack of guidance could lead to teams doing their own thing. This also has an impact on deployment processes, especially if the chosen approach is to have additional projects within the same solutions as the main website project. Any build process would then need to be able to split these up for each target.

[lakesol]

I would also like to propose something else which is related. The standards/accepted practice at the moment mean that web project types are used for every foundation/feature/project project. It should be clarified that projects/assemblies can be a class libraries too. Often we need base foundation logic (helper functions, extensions etc) which can be shared over multiple platforms (and not always websites). e.g. Windows Services. So weight/complexity can be removed and code re-use improved by allowing clean class libraries with little or no dependencies on System.Web/Sitecore to be included in the solution, underpinning both the website(s) and external targets/services.

[nickwesselman]

@lakesol

The standards/accepted practice at the moment mean that web project types are used for every foundation/feature/project project.

I don't know of any guidance in Helix that advises against this, the docs state that

A Visual Studio solution can host a number of different project types, such as Web Application projects, unit test projects, Team Development for Sitecore (TDS) projects, behavioural testing projects, Xamarin projects, etc.

https://helix.sitecore.net/principles/visual-studio/projects.html

I suppose Class Library could be mentioned explicitly.

[lakesol]

@lakesol

The standards/accepted practice at the moment mean that web project types are used for every foundation/feature/project project.

I don't know of any guidance in Helix that advises against this, the docs state that

A Visual Studio solution can host a number of different project types, such as Web Application projects, unit test projects, Team Development for Sitecore (TDS) projects, behavioural testing projects, Xamarin projects, etc.

https://helix.sitecore.net/principles/visual-studio/projects.html

I suppose Class Library could be mentioned explicitly.

Yes I am not sure its specific now in the docs, however its the case of the habitat example and also the available tooling such as yo helix. I am very comfortable using class libs in this way, however I have had some devs speak to me about it thinking that it is precluded (not standard). So a clarification would be great.

[dsolovay]

I suppose Class Library could be mentioned explicitly.

Do class libraries support deployment of static files? Not being able to push a config file limites configuration options, which is why, I thought, Web projects were used in the demonstation code (Habitat, and trainings).

If using a Class LIbrary means that a module cannot push configuration to Sitecore XM, then that is agument against using class libraries in most cases.

[lakesol]

I suppose Class Library could be mentioned explicitly.

Do class libraries support deployment of static files? Not being able to push a config file limites configuration options, which is why, I thought, Web projects were used in the demonstation code (Habitat, and trainings).

If using a Class LIbrary means that a module cannot push configuration to Sitecore XM, then that is agument against using class libraries in most cases.

I understand you mentioned "most cases" however let me explain a example I have.

It depends on what you are including in class libs. In a real world project I am working on we have Sitecore integrated with a ESB/message bus system (yes I know Sitecore is releasing their own). So this micro architecture approach has the Sitecore Instance plus a number of message subscriber applications (running outside of Sitecore). This needs contracts to be shared/common between the Sitecore solution and the subscriber applications. So these are in a common vanilla .NET class lib, referenced by all applications. The subscriber applications are not web apps, so we don't wont all the web dll collateral that would come with the contracts project if it was a web site.

Now this is an edge case, however it does show a real use case where a class lib is the correct choice.

[petrhavlak]

We are right now evaluation deployment process in Azure DevOps from Helix repository with Sitecore 9.1. The greatest pain in the neck is obviously having some modules that are to be deployed on different roles and deploying one module (or even part of it) to multiple targets, so few files go to one role, few others to different role and so on (ma-ops, prc, xc-collect, xc-search + index webjob, cm). Best option for now appears as following:

1. Have Build pipeline for each Siteceore role, that would construct deploy package. That definition would be tailored to pick correct files/dlls from all respective modules or create for example JS plugins for Marketing activity UI
2. Release pipeline would deploy that tailored deploy package to desired instance. WebDeploy can also delete files after rename or removal.

In the future it might be possible to use custom config files located in repository, where developer would be able to specify targets to which modules should deploy to (in case that module is deployable as a whole).
Second optimization here can be cutting deployments for which there was no change since last deploy (could be checked in git history)

Or is there any better/standard solution for deployment to all those PaaS services?