Skip to content

Updating a platform subscription

Jump to bottom
José Maia edited this page Jan 20, 2017 · 7 revisions

How to update a subscription of the platform

We provide, in this github repository, a Powershell script, OmniaUpdate.ps1, that can perform the update process.

This script, given the identification of a resource group, a subscription and a website's URL, will update it to the latest version of the platform without any effort.

Prerequisites

To execute this script, you must have:

  • Powershell 3.0 or higher;
  • .NET Framework 4 or higher (installed with Powershell);
  • The Azure Powershell modules. Notably, we will require the AzureRM.Resources and Azure.Storage modules.

Running the script

The script receives three mandatory parameters:

  • WebsiteName: In the form https://<name>.azurewebsites.net;
  • SubscriptionName: The name of the Azure Subscription the platform was installed in;
  • ResourceGroupName: The name of the Azure Resource Group the platform was installed in.

Additionally, it has optional parameters:

  • Force: The -Force flag makes the process assume "yes" to any user input requested by the script. (on a case of a possible rollback or reupdate, "yes" will make it stop);
  • WhatIf: The -WhatIf flag displays all the details of a normal update, without performing any changes (x migrations with scripts detected, migrating to version Y...);
  • Version: The -Version parameter forces the migration to look for a specific version instead of the most recent version available in the update feed.
  • Slot: The -Slot parameter makes the migration upload to a slot of the web app instead of the production slot. If left empty or input as Production, it will replace the production slot.
  • ResourceNameString: The -ResourceNameString parameter determines if users want to have any new resources that are created in version migrations created with a specific suffix (e.g. the company name). If ommitted, it will parse the string used to create the web app and obtain the uniqueString from the ARM template).
  • FeedURL: Allows users to define an alternative feed to download from. Important in testing or if users want to mirror our updates.

Execution flow

The script first starts off by obtaining the list of all the available updates. Then, it asks the platform for its current version.

If we are working with a Slot deployment, the current version is compared to the one that already exists in that slot. We recommend the slot to be fresh every time a slot deployment is performed! It is possible to deploy to a slot even if it does not have the same version as the Production slot, but it can cause configuration inconsistencies.

If there is no specified version by the user, the update process will update the platform to the latest version available.

After picking the version, a check is made to see if we are updating to the same version that is already placed, or updating to an earlier version - in both cases, the user is prompted to confirm.

Afterwards, the script verifies if there is any migration between the current version and the desired version that requires script execution (see the Script Execution section in this document for an explanation).

If we are performing an update to the same version or to an earlier version of the platform, none of these scripts will be executed.

If any migrations were executed, the script waits for the site to restart, to avoid a race condition.

The next step is to update the binaries of the platform. To perform this, the script invokes an ARM template that uses a MSDeploy resource to place a package on the site we identify when launching the script.

After the binaries are uploaded, if we are in a Slot update, the script will prompt the user as to whether they want to perform the swap or not. If they want to perform it manually (e.g. warmup scenario, delayed updates), the script will print out a message informing that the swap was not performed, and complete its execution. Otherwise, it will perform the swap between the desired slot and Production.

Script Execution

Some versions of the platform require changes to the platform's configuration values (for example, adding new connection strings, or deleting unused configuration values, or adding new options for users to configure their platform). This is done by invoking Powershell scripts that are hosted together with the packages.

We invite users to check those scripts before they update, and ensure that any scripts that involve Resource Group-level configuration changes, such as adding new resources, are explicitly marked as Major releases, so that users cannot update "past" those versions without being aware of what they bring (for example, updating to version 1.200.300 from 1.200.250, when 1.200.270 is tagged as Major, will make the update stop and inform the users that they need to manually update to 270 first.)

Clone this wiki locally