Skip to content

Database upgrade testing #124

Closed
Closed

Description

Now that the first stable release is out, we need to ensure that subsequent releases are sufficiently backwards compatible. To help ensure backwards compatibility across releases, we should add upgrade tests. An example of what this might look like:

  • Create a database using the v1.0.0 libraries
  • Populate the v1.0.0 database with a mix of orchestrations, some completed, some running and waiting for events, and some pending (using scheduled start times).
  • Backup the database and check it into the Git repository
  • Create a test (or tests) in the vCurrent code that restore the v1.0.0 database, followed by;
    • Going through the normal app startup flow, which should auto-update the schema
    • Allow pending instances to start normally
    • Create new instances using the new instances
    • Resume existing instances
    • Query for all instances, old and new, asserting that all expected properties are available.

This should give us a good sense about whether any given PR is sufficiently backwards compatible with earlier database versions.

As we release new versions, we can add new tests that do the same thing, but starting from different previously released versions. For example, a v4 release could include tests that validate upgrades from v1 to v4, v2 to v4, and v3 to v4.

Ideally, we have a new upgrade test for every minor release (minor releases typically contain new features). New tests shouldn't be necessary for patch releases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions