we are finally getting ready to update our DataCenter app to confluence 10. This involves migrating settings from bandana to ActiveObjects (PluginSettings being totally unusable), and I would really like to test and especially debug the process. This complicated by the fact that now we have different app versions that are tied to specific confluence platform versions.
Any ideas how I can do this? We hitherto use atlas-run with a SDK docker container and an additional debug configuration (we couldn’t get atlassian-debug to work), and my naive idea was to setup everything with confluence 9 and the V9 compatible version of the app, and then just switch over to confluence 10 and the V10 compatible version but keep the target directory the same, in the hope that confluence would upgrade everything the same way as in production.
Of course this does not work, confluence 10 dev doesn’t want to start up with the “old” target.
For production testing we use the official atlassian confluence containers, and while I probably could test run the upgrade there, I can’t debug it.
What might be getting in the way is the SDK setup. The target directory usually contains a mix of runtime files, caches and home-like data, and Confluence 10 seems to be quite picky about starting up when anything from an older version is still around.
In theory, it should work if you separate those concerns: keep the same Confluence home and database, but use a fresh runtime for each version. Reusing the home + DB is what should trigger the upgrade, while reusing the target directory itself is probably what Confluence 10 doesn’t like.
One way to try this could be with the official Confluence Docker images: run 9.x with a mounted home and DB, then stop it and start 10.x against the same home + DB but in a clean container. Debugging should still be possible via remote JVM debugging. The same idea could also be applied with the SDK by using different target directories for 9 and 10 and pointing both at the same external home and database.
I’m not entirely sure if this will work out of the box, but it seems closest to how upgrades happen in production and might be worth a try.
Fortunately the migration did work out of the box, so I didn’t have to debug it. In a certain way I’m glad that the on premise line is coming to an end - not that many more incompatible releases on the horizon…