Migrations

Why Migrations

The idea is to introduce a standardized process for internal changes in the Avalanche tool which usually requires scripting.

By running these migrations, we don't require external scripting, encapsulating different subsequent internal changes in sort of a managed, reproducible way which also represents its history.

The concept is borrowed from databases where migrations are being applied to update database structures and its data to new versions of schemas and applications.

Limitations

Usually, migrations have a rollback path which can be applied in case of failures. This tool currently does not support rollbacks.

General Structure

• The application calls all migrations implemented when booting
• Each migration is iterated in order (the order is "enforced" via the index in the migrations map)
• Each migration checks itself if it needs to be applied
• The first migration that is applied prints a message to the user
• At the end of the iteration, it is checked if any migration ran. If one did, a closing message is printed
• If no migration ran at all, nothing is being printed

Implementation

• Migrations need to reside in internal/migrations
• Each new migration should be added to a separate file in the package
• Each new migration needs to implement a migrationFunc
• It adds itself to the global migrations map with the next available index
• Each new migration needs to check itself if it needs to be applied depending on what it does
• If it needs to be applied, it should run printMigrationMessage as info to the user
• Otherwise it doesn't need to print anything (to not add confusion)
• Every migration is expected to clean up after itself if needed