Alf Nilsson talks

One of the common problems I’ve heard seems to be how to deploy a new version of EPiServer UI. The ultimate solution is to keep all environments in sync while not disturbing the other developers that are working at the same time when one developer is upgrading to the latest UI. At the same time the client should be able to download and install Add-ons.

Quick brief of Add-ons

As you probably know, the EPiServer UI is an “Add-on” (NuGet-based, downloadable package) and managed in the Add-Ons Manager in basically in the same way as all third-party Add-ons.

In a typical installation, the add-ons can be found in the ModulesRepository folder and unpacked into the Module folder in your VPP directory.

Note that the version of your add-on needs to be in sync with the assemblies in the modulesbin folder in your web root directory!

When browsing to the Add-on Manager, the EPiServer.Packaging more known as the EPiServer Add-On Store Platform module scans your Modules folder to list what Add-ons are installed, which version they are and checks whether a new version is available.

You can read more on the Add-ons, how they work and how to create your own on Dmytro Duks and Sergii Vorushylos blogs.

Here are some suggestions on how to keep Add-ons synced

Shared VPP among developers

In many companies, there are several developers working in the same EPiServer project at the same time and they work against the same database, hence they need a shared VPP folder so that documents referenced from the database can be in sync.

The most common solution to this is to have a shared folder on the local network such as \\FileShare\VPP\AlloyTemplates\ and setting the physicalPath attribute on your VirtualPathProviders in EPiServerFramework.config to a folder on that file share.

Disadvantages

While this is an easy way to keep the same version to all developers when backstaging, some manual interventions are needed when one developer needs to have another version for a short while.

For example when one developer is updating an EPiServer add-on, the other developers will have a discrepancy between the VPP version of the add-on and the assembly version in the modulesbin folder until the new version is committed and the other developers have pulled the latest version.

An other disadvantage is also that you need to manually update the other environments such as STAGE or PRODUCTION since the modulesbin folder is probably your source control while the VPP folder is not.

Separating Modules folders and Content folders in VPP

My idea here is to separate Content and Module folders. A suggestion is to create a sibling to your web root folder called EPiServerModules and move your Modules and ModulesRepository folders from your VPP directory here.

First thing is to adjust where EPiServer searches for the UI modules:

• Open EPiserverFramework.config
• Find your Virtual Path Provider section with the name ProtectedAddons
• Change the physicalPath attribute to ..\EPiServerModules\Modules

Now when you’re browsing to your EPiServer UI, everything will work fine as far as I have found. But the Add-on Store Platform will not know what modules are installed hence it cannot find new updates for you to install.

Second thing will be to adjust where the modules are installed:

• Open web.config
• Find the episerver.packaging ConfigSection
• Add the following attributes protectedPath=”..\EPiServerModules\Modules” and repositoryPath=”..\EPiServerModules\ModulesRepository”

Add the EPiServerModules folder to your source control. If you are using TFS, make sure to check out these folders since the files will be flagged as read only until they are to be changed.

Now each developer will have an individual Modules repository and depending on how your deployment routines, it could be much easier for you to deploy your updated Add-ons.

Disadvantages

This will take about 60-80 MB of disk space per project on your local drive.

Also if you don’t make sure to backstage possible updated or added Add-ons from your environments you will probably loose what Add-ons you or your client have added since last deployment.

Conclusion

I still have some problems seeing the whole picture with the Add-ons.

It’s nice that it’s easy to download new versions and probably this increases how often EPiServer can release new versions. But the risk of things getting out of hand increases.

It’s hard to find a good balance between being confident that added files to the application is approved and tested by the EPiServer Partner and letting the client user add things (that might break the web site). A rule found on most developers is that everything that ends up in the web root should be found in the Source Control.

In this article my main focus has been to make the life more streamlined for the developers and preventing risks while deploying. Do you have any suggestions on managing the Add-ons and specially the EPiServer UI between environments? Please leave a comment below!