Is there a right way to upgrade dependency track?

[Weder77]

Hello,

I would like to know if there are sql scripts to migrate dependency track versions?

I'm currently on version 4.9.1 (production), and I'd like to upgrade to version 4.11.1. I've seen that some changes have been made on the database/api side, so to avoid breaking everything during the upgrade, I'd like to know what would be the best practice for upgrading ?

Thanks in advance for your help!

[nscuro]

Dependency-Track takes care of executing any database migrations on startup. So in the best case you simply start a container of the new version and everything's done for you.

If this is a production deployment you rely on, you should back up:

• Your database
• Your data directory (/data volume in containers)

Prior to upgrading. If anything goes wrong, you'll be able to roll back to your previous version.

[Weder77]

Hello,

Thank you for your reply.

My database is a SQL SERVER in Azure Cloud. I don't work with a local volume.

So if I simply change in my docker-compose.yml with the right version, the migration scripts will be done automatically when the connection to the database is made? I may be repeating myself but I want to be sure 😁

Thanks again !

[nscuro]

So if I simply change in my docker-compose.yml with the right version, the migration scripts will be done automatically when the connection to the database is made?

Correct. Still, please consider creating a backup of your database just in case.

I don't work with a local volume.

In that case, be prepared for any secrets (i.e. OSS Index token, GitHub access token, etc.) you may have configured in your instance to become invalid. The encryption key for those secrets is stored in the /data volume, so naturally if you're loosing it, DT will be unable to decrypt those.

[black-snow]

refs:

• https://docs.dependencytrack.org/getting-started/data-directory/
• https://docs.dependencytrack.org/getting-started/configuration/#secret-key

[Weder77]

Thank you for your answers. I forgot to mention that it was a database in Azure Cloud.

I'll be able to start the migration with peace of mind 😁

Have a nice day!