Skip to main content

Application upgrades

When a new version of an application is deployed to a site, the application specification contains instructions for how the new version is introduced in the site.

Upgrade methods​

The system supports two upgrade methods - stop-and-restart and per-service. These are described in detail in the reference documentation

The upgrade method is defined the the upgrade-from list in the application specification. A simple example could be:

name: popcorn
version: "2.0"
...
upgrade-from:
  - version-regexp: "."
    method: per-service
    services:
      - name: pop-service
        instances-in-parallel: 1
        healthy-time: 30s

This example says that the popcorn application version 2.0 can be upgraded from any other version (specifically, any version that matches the regular expression .). It will be upgraded one service instance at the time, and the system will wait 30 seconds after one service instance has been upgraded before upgrading the next one. If an error is detected during this time, the upgrade is aborted.

Forcing upgrade via a specific version​

The version-regexp should be specificed so that it allows as many previous versions as possible. Suppose that the system runs version 2.0, and that a site has an application upgrade window that allows upgrade monday nights. If versions 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5 are released during the week, it is often best to upgrade directly from 2.0 to 2.0.5.

However, in some cases it might not be possible to go from any other version to a new version. For example, the database schema might have changed in some particular way in version 3.0, and special code is present in 3.0 to handle this. This can be expressed in the following way:

name: popcorn
version: "3.0.1"
...
upgrade-from:
  - version-regexp: "^3\.0$"
    method: per-service
    services:
      - name: pop-service
        instances-in-parallel: 1
        healthy-time: 30s

This example says that version 3.0.1 can only be upgraded from 3.0. This means that if a site runs 2.0.4, and the application queue contains versions 3.0 and 3.0.1, the system will first install 3.0 and then 3.0.1.

3.1.2 may look like this:

name: popcorn
version: "3.1.2"
...
upgrade-from:
  - version-regexp: "^3\.0$"
    method: per-service
    services:
      - name: pop-service
        instances-in-parallel: 1
        healthy-time: 30s
  - version-regexp: "^3\."
    method: per-service
    services:
      - name: pop-service
        instances-in-parallel: 1
        healthy-time: 30s

This means that if 3.1.2 is introduced in a site that runs an earlier version than 3.0, the system first installs 3.0. If the site runs 3.x, it can be upgraded directly to 3.1.2.