2

For upgrades, Sitecore stores summary info and a rollback (.rlb) file in Website/temp/__UpgradeHistory for each upgrade that is done to provide a way to undo the package installation.

This occurs for Sitecore's upgrades, but also for any deployments done using .update files, such as TDS.

Is there a way to temporarily disable this in situations with no risks associated with it to speed up performance? Through config, for example?

My desired scenarios would be full deployment to a test environment or dev machine. Any improved performance for that would be desirable. Full deployment currently can take upwards of an hour to accomplish via TDS, and I suspect if Sitecore did not have to create rollback info for every item that is touched, the deployment time would improve substantially.

Improve this question
2
  • While your question is specific, there are many unknowns regarding how your deployments are set up. What are you using as a build server? Deployment tool? How are you using TDS to assist with deployments- there are several ways to use it. The more detail you can provide the better. While disabling history might save a little time, I imagine there are other ways to save significant time.
    – jrap
    Feb 20, 2018 at 1:58
  • 1
    I wanted the question to be specific because I believe the more focused a question is, the better that question itself can be answered. This particular question came up from a discussion with our infrastructure architect regarding Rolling back your TDS deployments, which I was researching for alternatives to DB restores. As an aside, he asked if the .rlb files could be turned off in any way, so I've been trying to research that specific question as opposed to a generic "how do I make this faster?"
    – jeremyr
    Feb 20, 2018 at 16:29

1 Answer 1

Reset to default
3

I wrote the article about creating rollback packages that you linked to in the comments and dug into the installation process a fair bit. Generally speaking, .update package are used by Sitecore for upgrade purposes and .zip packages are generated by the Package Designer for packages items and files. When the zip packages or modules are installed they do not create rollback file, but by design .update files always create a .rlb rollback file. For it's intended purposes, this made sense: a customer tries to upgrade, something might go wrong, the rollback and installation history can be used by Sitecore Support to diagnose the upgrade issue.

The packages generated by TDS has piggy backed on this package format, and the reason for using .update format and not .zip is to allow the files to be installed and overwrite any existing files/configs with the same name. If .zip were used then config files could not be overwritten and they would instead be left in a disabled state.

There is no out of the box way to disable the rollback file generation when .update packages are installed, either using config settings or disablers, using the Update Installation Wizard, Sitecore Ship or any of the other package installer modules that I am aware of.

Internally in the Sitecore package installer code there are a number of checks in the code whether the rollbackPackagePath folder has been set, and if not then the package is not generated. If you write your own wrapper around this code then it is possible to disable generation of the rollback file. There are a number of overloads in the InstallPackage() method of the Sitecore.Update.Installer.DiffInstaller class, the overloads you are most likely interested in is one of these but be sure to check the others:

public List<ContingencyEntry> InstallPackage(string packagePath)

public List<ContingencyEntry> InstallPackage(string packagePath, string rollbackPackagePath)

public List<ContingencyEntry> InstallPackage(string packagePath, string rollbackPackagePath, string logFolderPath)

public List<ContingencyEntry> InstallPackage(string packagePath, string rollbackPackagePath, string logFolderPath, ILog installationProcessLogger)

public List<ContingencyEntry> InstallPackage(string path, InstallMode mode)

public List<ContingencyEntry> InstallPackage(string path, InstallMode mode, ILog installationProcessLogger)

You can then install the package using the appropriate overload, for example:

var path = "C:\path\to\MyProject.TDSMaster.update";    
var installer = new DiffInstaller(UpgradeAction.Upgrade);
diffInstaller.InstallPackage(path, InstallMode.Upgrade)

Remember to also call DiffInstaller.ExecutePostInstallationInstructions() if you have Post Deployments steps added to your TDS package.

If you are using Sitecore.Ship for your update package installation then you can clone the repo and the make the change to the code which installs the package. It would be fairly simple to pass in an additional "disableRollback" flag to allow you to run both modes with an additional parameter similar to how disableIndexing works. Be sure to read Working with the Sitecore.Ship Source Code in the readme file, it's simple to build a custom nuget package afterwards which you can include in your project as a file based location sourced if needed.

You can also make use of the SPE [Install-UpdatePackage2 command and make use of remoting to install the packages. You can take a look at the code that is used to run this command in the Github repo. For example:

Install-UpdatePackage -Path "C:\path\to\MyProject.TDSMaster.update" -UpgradeAction Upgrade -InstallMode Install
Improve this answer
3
  • Thanks for the thorough explanation, I really appreciate that! I ended up digging through Sitecore's code yesterday myself and the stuff you mentioned definitely makes sense. I also noticed that if you use Install-UpdatePackage from PSE, it does not create the .rlb when you install with their method -- but that appears to be a defect. They have a "RollbackPackagePath" parameter, but it does not get used. Apparently there is an overload for Sitecore.Update.Installer.InstallPackage() that doesn't take a RollbackPackagePath, and ends up passing in a null value, which just ignores a rollback file.
    – jeremyr
    Feb 21, 2018 at 16:36
  • Slight correction to previous comment -- Sitecore PSE uses Sitecore.Update.Installer.DiffInstaller, which extends Installer, to call InstallPackage(). There is an overload of it that takes no rollbackPackagePath, which then eventually passes null to CreateInstallationContext(). When it attempts to setup the rollback, it checks String.IsNullOrEmpty(path), and if it is, just returns early without setting up a rollback writer (BaseSink<PackageEntry>). Without that, the code is never set up to create the .rlb, and it eventually gets ignored.
    – jeremyr
    Feb 21, 2018 at 16:56
  • Yes, I just checked with some fresher eyes I missed the overloaded method which allow you not pass the rollbackPackagePath string. I'll update the answer, but as I mentioned not setting rollbackPackagePath causes the rlb not to be created. Somehow I completely missed overloads
    – jammykam
    Feb 21, 2018 at 18:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.