Problem Definition

Database version or log of upgrade tasks are not currently recorded within the Bamboo database and there is nothing to prevent Bamboo from starting / re-running / skipping upgrade tasks on an already upgraded (or not upgraded) database. This is sometimes very obvious or goes completely undetected until integrity issues present further down the track.

Problems typically present in upgrade and rollback situations where mismatches occur between the version stored on the filesystem vs the state / version of the current database.

Suggested Solution

• Bamboo version stored within the database that reflects the current database state aka 'Database schema version'
• Audit log within database of upgrade tasks that have been run, with timestamp and status (e.g. success or failure). Ideally these log entries would be easily grouped with an identifier per upgrade attempt and show the detected version and the target version aka 'Database changelog table'
• Proactive validation that would prevent Bamboo from starting if a mismatch is detected. This should be clearly displayed in the UI (as opposed to a generic fatal bootstrap error) with an explanation of the error. The concept of filesystem version vs database version and it's importance in our upgrade procedure isn't common knowledge to a lot of Bamboo Administrators.