Deployment and Cloud support

This post is most an overview of the changes we have done around deployment and how a site is “packaged”. There are much more information about deployment and cloud support in the CMS SDK under “Developer Guide/Deployment”. For example can information/examples about deployments to Azure and Amazon be found there.

XCopy enabled deployment

In EPiServer 7.5 we have changed how a site is “packaged” so deployment of an EPiServer CMS site can be done through XCOPY deployment simply by copying application files. An XCOPY-style file transfer simplifies deployment and maintenance of EPiServer sites since no registry entries are created, and no shared components are registered. Examples of XCOPY-style hosting is Azure Web Sites and Amazon Elastic Beanstalk, where basically only a IIS instance is provided, and it is not possible to run an installation setup procedure.

Note: We do not say that you should use XCOPY deployment as such, you should of course use the deployment that suits your hosting environment. But making deployment copy enabled should benefit other deployments as well like e.g. MSDeploy, FTP and external deployment tools.

Another benefit of the XCOPY architecture in EPiServer CMS is that there is no machine- or site-specific information stored in configuration files, making it possible to use a shared folder for multiple servers. During development in a shared environment with source control, developers can keep configuration files checked in and still be able to create a site which can be duplicated in a multi-site deployment.

Another change that is related to copy enabled deployment is that we have removed the usage of Windows service for CMS. This means that the scheduled jobs are maintained within the web application it self.

Cloud support

Another change we have done to make it easier to scale an EPiServer installation by adding/removing IIS instances/machines is that we have changed so “services” like Blob storage (replaces previously used VPP based files) and event management (between sites) is provider based. The idea is that one IIS instance running the site only have knowledge about the services and not direct knowledge about other running web site instances. Then it is possible to add/remove one instance without having to touch the other running instance. A conceptual picture of this is:

There are separate NuGet packages EPiServer.Azure and EPiServer.Amazon in our feed that contain Blob providers and event providers for each of those environments.