Posterous theme by Cory Watilo

Upgrading our mojoPortal install

It seems no matter how many times I've upgraded mojoPortal, I'm always at a loss as to where to begin. I've done it enough to know that it's nothing to be afraid of, but it does take some elbow grease. In addition to making sure that the upgrade goes smoothly in itself, I also always have the concern of leaving the version control system which I use to track my customizations in a working state.

This second comes into play primarily because the mojoPortal upgrade approach which I take is a customization forklift onto an entirely new set of code. I don't try to overlay the update on the old site. Rather, I unzip the new code and bring over all of the customizations. This means that from a version control perspective, I'm not making modifications to an existing family of changed files, I'm nuking the files back to zero and redoing all of my customizations on top of them. If I'm not careful, this has the effect of collapsing all of my history into one big changeset, and I don't like losing that history.

But before delving into too much detail on the version control, focusing on the upgrade itself is the primary concern.

The overall process goes:

  • review and commit any pending changes
  • backup the database
  • get the new code
  • migrate all of the customizations over (getting the vc right)
  • stop the web service
  • switch the new directory in for the old one
  • start the web service
  • visit the setup page for the new version (http://support.diditbetter.com/Setup/Default.aspx)
  • Check the security settings from the administrative interface
  • backup the old directory

You always want to make sure you check the mojoPortal release notes for the releases between your last and this one to see what caveats there are about this version.

Sometimes there are considerations for skins as well in the new version. Usually old skins won't break, but there are pages on the mojoPortal.com site which discuss upgrading skins.

Why do an upgrade by customizing the new code instead of dumping the new files on top of the old site? In the end, it's because it's generally the same amount of work and ends up with a cleaner install. Here's the reasons:

  • Sometimes files are removed or renamed in the new version. If you just overwrite the old directory, the old files won't be removed, and while this usually shouldn't matter, why take the risk?

  • Many configurations would be overwritten if you just copied over the old site. While the binary files need to be replaced, and even the configuration files need to be updated with new settings, the old customizations would get removed by simply dumping on top of the files. While user.config handles some of this, there are still customizations that occur to web.config and other files which can't be lost.

So, here are the steps in more detail.

Review and commit pending changes

  • Log into mojo-a and go to E:
  • Right-click diditbetter and select Hg Commit
  • Review any changes and commit them if desired
  • Go to \diditbetter\Data\Sites and visit the skins directory under each site
  • In each skins directory, right-click any custom skin (like diditbetter3) and review and commit any changes if desired

Backup the database

This can be done easily from SQL Management Studio.

  • Log onto mojo-a
  • Open SQL Management Studio
  • Connect as sa
  • Open Databases
  • Right-click mojoportal and select Tasks > Back Up
  • Select type Disk and click Add...
  • Name the file mojoportal.sql.[YYYY]-[MM].bak, where YYYY is the four-digit year and MM is the two-digit month
  • Put it in the default backup directory
  • Click OK until the backup is performed

Get the new code

  • Go to http://mojoportal.codeplex.com/
  • Download the latest .NET 4, MSSQL deployment files (generally this is the default download)
  • From the zip, copy the wwwroot folder to E:

Check whether there are skin modifications with the update

Usually, the changes that affect the skins are in the theme.skin file, which may or may not be customized by us, so check the repository history for the theme.skin file before just overwriting it with a new version from the upgrade's default artisteer skins.

Migrate the customizations over

This is the hard part. Not only do the files have to be right, the filesystem permissions need to be correct as well.

  • In wwwroot, delete Data\Sites (usually there will be one site called 1)
  • From diditbetter, copy Data\Sites to wwwroot
  • In each of the sites in this copy, delete all skins which aren't necessary (Data\Sites\[site number]\skins). Leave the custom skin for the site.
  • Copy the printerfriendly skin from \wwwroot\Data\skins
  • If you need skins in the future, copy them here from Data\skins, which are up to date with the latest version
  • Create a new repository in wwwroot
  • Copy .hgignore from diditbetter to wwwroot. It should contain one line: glob:*
  • Right-click e:\diditbetter and select Hg Workbench
  • Review the changelog for the site and make sure all of the changes make it over. First, copy user.config.sample to user.config and add the upgraded version of edited files to the repository (the ones that came in the zip, prior to editing). Then move over the edits (don't just drop the old files over the new ones!) one by one, committing them with the same commit messages as they had in the old repository. WinMerge is good for this so you don't just overwrite the new file with old baggage. This should include:
    • Basic web.config and user.config settings
      • UseRelatedSiteMode on so that the same user db is used across sites
      • The machine key is preserved from the old site, otherwise logins won't work
      • The database connection string is brought across
      • Email settings are configured
    • More user.config optimizations
      • UseKeepAlive is set to keep the site responsive
      • Notify admins on new registrations is on
      • Show the "rebuild search index" button to admins
      • Allow forcing of the preferred hostname for the site
    • Custom registration configuration
      • CustomProfile.config added
      • App_GlobalResources.resx edited with new fields
      • user.config configured with name of CustomProfile.config
  • Additionally, you have to copy over these files:
    • iirf.ini is the configuration file for URL rewriting/redirection
    • These files are for IIS to do redirects:
      • activate.aspx
      • blog-rss.aspx
      • downloads.aspx
      • news-rss.aspx
      • support-rss.aspx
    • Any custom scripts in the ClientScripts directory should be copied over including:
      • coda-slider.js
      • jquery.localscroll-1.2.5.js
      • jquery.scrollTo-1.3.3.js
      • jquery.serialScroll-1.2.1.js
  • Set the file permissions for Network Service on the wwwroot folder
    • Add Network Service to the top level with default rights plus an explicit deny for Write
    • Go to the Advanced settings, select Replace permissions... and click Apply
    • Add an explicit allow for Write for Network Service to the App_Data and Data subdirectories, also forcing it onto all subfolders and files
  • Stop the W3 service, rename the old diditbetter folder and name wwwroot in its place
  • Start the W3 service, then visit: http://support.diditbetter.com/Setup/Default.aspx. This will take some time since the site has to recompile all of its files.
  • Zip up the old site directory and archive it for safekeeping

Once the upgrade is complete, put the system through its paces, keep an eye on it for a while and check the event viewer logs for errors.