6

Sitecore Support recently changed their strategy when delivering support packages. We do no longer get a patch for a specific issue - instead we get a whole package including items & files that contain all patches for our specific version so far. Cumulative patches. Sounds great.. and we just installed one on our test environment. But then came DevOps.

So we used to have all our support package file referenced into our solution - as they got included in the deploy package that worked fine locally and on our PaaS setups. All files were new compared to a vanilla Sitecore so nothing got overwritten.

In the new package, we can find dll's that will overwrite the ones from Sitecore. This is no issue when we install the package. We can transform the files from that package into a zip or deploy package that we can use in our DevOps process to PaaS to make sure it is deployed after our solution. But.. I am struggling to find a good solution for a local setup.

I can (will) install the package locally to have the items installed. But when I deploy my solution I will overwrite the support dll's again with the original ones (from Nuget). I do not want to stop using Nuget and reference the support dll's everywhere needed (that would be a recipe for disaster anyway). If there would be a way to deploy those files after my solution that would be nice - but I didn't find a good way to do that yet.

Note that the solution is Helix, with several projects.. sometimes I publish just one feature (if that is what I'm working on), sometimes I publish the whole solution.

Long story.. small question: does anyone have a good DevOps approach with the new support packages (incl local)?

  • why are you deploying Sitecore DLL's with your DevOps? – Richard Seal Nov 18 '19 at 17:06
  • 2
    I reference them via Nuget, and those get included into the solution and deployed. – Gatogordo Nov 18 '19 at 19:06
  • 1
    But why? You should be excluding Sitecore binaries from deployment. That solves the issue instantly. There is no reason to re-deploy Sitecore binaries that are already there from the install. – Richard Seal Nov 18 '19 at 19:49
4

So what we are usually doing (and I have recently seen that others are doing this as well) is keeping a separate Infrastructure Solution. This is usually done when you have an Ops team in place and is responsible for keeping the Ops stuff of the solution (for example ARM Templates, Terraform files etc.).

When you create such solution this becomes your main source for Instance configuration files i.e. non-feature/foundation patching of Sitecore and more generally the things that go into your Environment folder of your App_Config. We also use this solution to deploy the Sitecore Patch Files (in the past Sitecore.Support.*.dll) across environments.

In multi-site environments, especially in the pre-Helix era it was helping a lot to keep a consistent environment that was hosting multiple solutions with not so shared codebase.

This solution is living its own life - meaning it has it's own build/release pipelines in order for us to be able to deploy business critical support fixes as quickly as possible (we all know about the security bulletin madness ;)) It can also either live within your main repository or in a completely separate repository (honestly a matter of personal choice).

This of course implies that your main solution is NOT deploying any Sitecore assemblies as Richard already said.

So basically if you apply his recommendations to your local solution and separate the support patches into a separate solution which can have it's own publishing - you can manage this locally by having a README that states that you must deploy the Infrastructure solution before you deploy your main solution or you can directly integrate it into your current Build Full Solution process.

Also keep in mind that if you host the solution within you can re-use the same publishing resources like .publishtargets etc, between both solutions.

|improve this answer|||||
1

I would recommend that you exclude the Sitecore binaries from your deployment. This would prevent them from overwriting any existing Sitecore binaries, any Sitecore patch/hotfix binaries and also it stops errors happening when you might reference the wrong Nuget version of Sitecore and deploy... that is always fun.

msbuild

Ways to do this, depend a bit on how you deploy. For a straight MSBuild webdeploy, similar to how the Habitat gulp script works. I would have a shared publishsettings.targets file and reference this in each web projects .pubxml file. You can use the <ExcludeFilesFromDeployment> tag to tell msbuild which files to ignore:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <publishUrl>http://mysite.local</publishUrl>
      <ExcludeFilesFromDeployment>
          packages.config;
          bin\Sitecore.A*.dll;
          bin\Sitecore.C*.dll;
          bin\Sitecore.E*.dll;
          bin\Sitecore.K*.dll;
          bin\Sitecore.M*.dll;
          bin\Sitecore.FX*.dll;
          bin\Sitecore.XA.*.dll
          bin\System.*.dll;
      </ExcludeFilesFromDeployment>
  </PropertyGroup>
</Project>

Notice I have a set of patterns here vs Sitecore.*.dll so that hotfix dlls can still be deployed.

Helix Publishing Pipeline

If you are using the Helix Publishing Pipeline method, you can use the HelixPubishing.Website.wpp.targets file with the <SitecoreAssemblyListsToExclude> :

<ItemGroup>
    <!-- Exclude Sitecore Binaries from publishing -->
    <SitecoreAssemblyListsToExclude Include="AssemblyLists\*.csv" />

    <!-- Exclude the publishing website from publishing -->
    <SitecoreAssembliesToExclude Include="HelixPublishing.Website.dll" />
    <SitecoreAssembliesToExclude Include="Sitecore.XA.*.dll" />

    <!-- Include Patched Assemblies-->
    <SitecoreAssembliesToInclude Include="System.Web.Mvc.dll" />
</ItemGroup>

We use a CSV of all the assemblies that you can download from Sitecore:

enter image description here

|improve this answer|||||
  • 2
    The hotfix dll's in Sitecore 9.1 + are the same names as existing dll's (Sitecore.Kernel.dll, Sitecore.ContentSearch.dll etc) – Mark Gibbons Nov 18 '19 at 23:10
  • A different publish setting can fix that - which is what Nicola is actually saying in the other answer. Now I wish I could accept both answers... – Gatogordo Nov 19 '19 at 9:09

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.