...

Once you've published your updated container images (see below), run ./update_and_restart.sh from within this the deployment directory on the server.

This will pull the updated images, stop, and restart the containers with the new images.

...

While we make use of a staging environment, this the database has a tendency to fall way out of sync with production/live. Generally then it's used as a first test, to ensure new releases deploy without errors.

Occasionally though, we implement changes significant enough that we want to internally test them within the production/live environment. To do this, we make use of the edge tag on our docker images.

...

If the most recently published image was a stable release, edge and latest will point to the same image, and all users will be served the same version. This should be the state the application is in most of the time.

Setting Versions

Both https://github.com/renalreg/ukrdc-fastapi and https://github.com/renalreg/ukrdc-nuxt-3 have a setversion.sh script in their repositories to simplify setting application versions.

Use ./setversion.sh {version_number} to set the application version. E.g. ./setversion.sh 4.0.0-beta.1.

You can also use ./setversion.sh major, ./setversion.sh minor, and ./setversion.sh patch to automatically bump the version number by the appropriate amount for that type of release.

Versioning https://github.com/renalreg/ukrdc-fastapi

...

• Major version changes should be accompanied by a breaking change in the API.

  • E.g. removing or changing the schema of returned data in existing API routes.

• Minor version changes should be accompanied by a non-breaking change in the API.

  • E.g. adding new, additional data to existing routes, or adding new routes entirely.

• Patch version changes should be accompanied by fixes or updates introducing no new API functionalitychanges.

  • E.g. bug fixes.

Versioning https://github.com/renalreg/ukrdc-nuxt-3

...