• The build process should be totally automated
• Building the site should result in a release package
• The build server should run unit tests, code analysis and test code coverage every time the build is run
• The deployment process should be totally automatic (for the test environment and for the production environment)
• It should always be possible to rollback an update (files, database, IIS-settings, etc.). Rollback should also be fully automated.

I am very happy to say that we have fulfilled all our above goals, let me tell you have we did it.

Build process and the release package

We are using TeamCity as build server. TeamCity is great build server which support numerous different build agents and it hooks up very easily with our Mercurial version control system. This is what a typical check in/build/package scenario looks like:

1. 1. A developer checks in new code
2. 2. TeamCity picks up the change from Mercurial and starts a build
3. 3. Once built TeamCity runs all the units tests, code analysis and code coverage
4. 4. If the unit tests are successful the TeamCity creates a deploy package. The package contains a MSDeploy zip file, configuration files and our deploy tool chain (Powershell scripts and a few executables) – everything you need to deploy the site.

By downloading and extracting this file you get a file structure that looks like this:

Scripts – contains various scripts needed to perform deployment, the most important being Deploy.ps1 and Deploy-Local.ps1.

SiteConfig – contains shared settings and one directory per unique environment (AT = Acceptance Test, ST = System Test, Dev-PM = My development environment). In the SiteConfig directory we also find the following files:

• settings.xml
• episerver-config.master.xml
• episerver-config-site1.xml
• episerver-config-site2.xml

The settings.xml is the base of all non-episerver settings. It contains connection strings to databases, paths to where the web site should be installed, where logs should be placed, where VPP files are placed, integration settings to external systems and much more.

In each environment specific directory, such as “AT” it is possible to override these settings by creating a settings.xml. The new settings.xml does not replace the one in the parent directory, it is merged with it and the environment specific file takes precedence over the general.

A simple example let pretend this is our \SiteSettings\settings.xml:

<settings>
  <webDir>D:\WebSites\</webDir>
  <logDir>D:\Logs</logDir>
</settings>

Say that I would like to override where the logs are stored in my ST environment. To do this I would create \SiteSettings\ST\settings.xml, containing:

<settings>
  <logDir>C:\Temp\Logs</logDir>
</settings>

The merged config would be:

<settings>
  <webDir>D:\WebSites\</webDir>
  <logDir>C:\Temp\Logs</logDir>
</settings>

We use this for both development and deployment. When a developer checks out the source code, there is a “Init.ps1” script in the Scripts folder (not included in the release package). This script will setup the website according to the specified settings (in my case the Dev-PM folder). The script configures the local IIS server, creates app pools,  creates the sites, sets permissions on folders, creates local MSMQ queues, configures NServiceBus and so on. Thanks to this script all the developers have a development environment that is nearly identical! Super sweet!

Ok, back to deployment. As you might have figured out, the episerver-config.master.xml serves as base for all episerver sites. Since this is an enterprise installation we can have several sites and each –siteX represents such a site.

All the settings in the files are overridable in the same way as with settings.xml. We use this to, for example, provide the appropriate license file for the specific environment.

SiteWebDeployPackage

This might be the least exciting directory, it simply contains a MS WebDeploy package created by MSBuild. This package contains everything needed to run the sites, except for the site specific configuration files that Deploy.ps1/Deploy-Local.ps1 will put in place.

Tools
This directory contains our “deploy tool chain”. The tool chain includes, MSDeploy.exe (WebDeploy), SimpleScriptRunner.exe (DB migration), 7za.exe (zip) and a bunch of other tools needed to setup and install Msmq and NserviceBus.

The deploy process

When we started implementing the automated deployment we were hoping to be able to do most of the heavy lifting in WebDeploy. But after a lot of research and testing we came to the conslusion that it was probably possible to do what we wanted to do in WebDeploy (WebDeploy is very powerfull), but we could not figure out how. The WebDeploy documentation at that time was almost non-existent and had few advanced examples. Instead we made the decision to use PowerShell for most of the work and use WebDeploy only as a method to package transfer files.

This is the steps needed to perform a deployment:

1. 1. Download the latest release package from TeamCity
2. 2. Extract it, start PowerShell and cd into the Scripts folder
3. 3. Run “Deploy.ps1 <environment>”. The addresses of the servers are confgured in the environment settings

This is what Deploy.ps1 does:

1. 1. Remotes to the service bus host and takes it offline
2. 2. Remotes to the webserver and takes the site offline
3. 3. Creates a backup of the entire IIS containing all its settings and sites using WebDeploy (used if rollback is carried out)
4. 4. Creates a backup of all databases (used for rollback)
5. 5. Uses SimpleScriptRunner to connect to our database server and apply database schema updates on our databases (not the EPiServer database)
6. 6. Copies the deploy package to the webserver
7. 7. Remotes to the webserver and runs Deploy-Local.ps1. The script installs the files, configures IIS, copies license files, etc.
8. 8. Starts the site and the service bus and runs runs integration tests
9. 9. Print result and exit!

If the update of some reason is not working as it should, the update can be easily rolled back by executing “Deploy.ps1 <environment> -Rollback”. This will restore all affected system to exactly the same point as they were before the update.

Conclusion

Automating the build and the deployment process is absolutly worth the effort it takes to implement it. By automating the process we have been able to catch more bugs, develop and release faster and at the same time make the entire process less dependent on certain people in the group – our knowledge is documented in the build and deployment scripts.

A very nice bonus from this is that we can version control everything related to the site, IIS settings, EPiServer settings, EPiServer Licenses and much more. Also, installing the release on a “empty” server is as easy as updating an existing installation.

The tools that made all this possible:

Microsoft WebDeploy – Deployment tool from Microsoft.

Psake- Build automation tool written in PowerShell (inspired by rake in Ruby).

SimpleScriptRunner - Tool to run a directory of numbered sql scripts against an MSSQL database.

OpenDBDiff - Tool/library to generate SQL-diff scripts.

PageTypeBuilder – Automatic synchronization of pagetypes in EPiServer (page types are defined in code)

I did some research online to see what others had done. I found two great posts by Joel Abrahamsson and one from Fabio Fabrizio, who based his solution on Joels experiments.

Joels first attempt was to create a base class from which all Controllers inherited. However, this made the controller do more than it should and made it very hard to test. His second attempt was to create a custom model binder and make every action receive currentPage as a parameter. This approach makes it much easier to create unit tests for the code, since it is now possible to moc the currentPage parameter.

Fabio took a different approach and decided to implement a custom MVC handler and a controller factory. This approach fits very well with MVC and felt like the right way to go, so I decided to create a prototype based on Fabios code. Fabios code was based on EPiServer CMS 5 and ASP.NET MVC 1.0, but I wanted to use EPiServer 6 and ASP.NET MVC 2.0, so I started porting the solution.

Porting the solution to EPiServer 6 and ASP.NET MVC 2.0 required some changes to both code and configuration, which not all of them was trivial. At the moment I have a prototype up running, and it works remarkably well! I will continue my experiments and post my results.

Prev 1, 2 , 3, …, 99 Next

A fairly normal approach to this would have been to use a query parameter for handling the paging. Like this:

By using this approach each page would have a unique entry point, using query strings is however not optimal for SEO, but even worse is using asp:LinkButtons. Whoever created the site had decided to use asp:LinkButtons. LinkButtons are very convenient to work with in ASP.NET, but the HTML code they generate is not very SEO friendly. This is the HTML that was generated:

We can see that:

• LinkButtons generates a javascript that is run when the link is clicked, instead of using a normal link
• Paging is handled using a postback, the pages will no longer have unique entry points.

This is disastrous from a SEO perspective.

So lets fix it. First step is to replace the LinkButtons with normal links (asp:Hyperlink) – and then we are going to do some URL rewrite magic to create SEO-friendly URLs. The code behind was changed to assign links like /products/?page=4.

Now, to get URLs like /products/page/4, we can create a custom url rewrite module in EPiServer. First we create a new class, Rewrite, that inherits from EPiServer.Web.FriendlyUrlRewriteProvider. In this class we override three methods (don’t ask we why they have such confusing names, someone at EPiServer must have been under the influsene of something when nameing them):

• ConvertToInternalInternal - Used to convert from /product/page/4/ to an internal EPiServer page with the page id as a query parameter
• ConvertToExternalInternal - Used to convert from an internal EPiServer URL (/PageType.aspx?lotsofqueryparameters=values) to an external (/products/page/4/)
• ConvertToInternal - Needed to work around URL rewrite caching behaviour in EPiServer, will get into more detail on this later.

This is the class:

The first method we implement is the ConvertToInternalInternal which will convert the URL to an internal EPiServer URL.

While not nessesary, we should override the ConvertToExternalInternal as well. This will let EPiServer automatically convert internal urls containing the dqcPagingId querystring to a external url ending with /page/{Id}/.

Now one can think we would be done, but there is one more method we need to implement. EPiServer uses a cache to cache URL rewrites from external URLs to internal URLs, but it will only cache the querystrings used by EPiServer, not the dqcPagingId we added. This gives a rather unexpected result. The first time the page is loaded everything loads fine, from code behind we can access the dqcPagingId and show the requested page. If you wait 10 senconds (default cache time) or more and reloads the page, it works fine. But if you reload the page sooner, the dqcPagingId will not be set when the page loads. This is because the querystring dqcPagingId is not cached by EPiServer. This took me quite some time to figure out.

The solution to the problem is to override ConvertToInternal to bypass the default caching:

The last step is to add our Rewrite module to the web.config:

Now we should be all done! Enjoy!

Rename a Folder

There is no Rename method on the EPiServer.Web.Hosting.UnifiedDirectory class. To rename a folder you need to call the MoveTo method as follows:

1.  
2. protected void RenameFolder(string path, string oldName, string name)
3. {
4.     if (IsFolder(path))
5.     {
6.         UnifiedDirectory directory =
7.         System.Web.Hosting.HostingEnvironment.VirtualPathProvider.GetDirectory(path) as UnifiedDirectory;
8.  
9.         int e = -1;
10.         while (path.IndexOf(oldName, ++e) > -1) ;
11.  
12.         StringBuilder sb = new StringBuilder();
13.         sb.Append(path.Substring(0, e – 1));
14.         sb.Append(name);
15.         sb.Append("/");
16.  
17.         directory.MoveTo(sb.ToString());
18.     }
19. }
20.  

What a convenient way of renaming a folder Good thing that you don’t have to do it too often.