Reinstallation after rollback yields errors

Legacy Operations
1

Upgraded from 2018.8.9 to 2019.3.0 LTS and lost all nuget packages, projects, everything. Looked like it had been a fresh install.

So I pulled a backup and restored the database, then uninstalled OctopusDeploy and installed 2018.8.9 (what the database backup said was last installed).

Now experiencing these issues:

  • /app#/projects, /app#/tasks and /app#/configuration/audit all yield the same exception:
  • Clicking the search icon in the main navigation yields the message:
  • Projects set to trigger a new release & deployment when a package is uploaded isn’t working. I am able to manually create a release and see it deploy.
3

Hi Jeff,

I am so sorry that this ticket didn’t get correctly picked up, that is my fault.

Are you able to advise if this is still an issue for you or if you have resolved your issues post upgrade?

If you can let me know that would be greatly appreciated.

Regards,
Alex

4

I managed to resolve the errors I was seeing by fixing the project JSON. Approximately 12 projects had a ReleaseCreationPackage value of NULL. This meant it couldn’t map to the object properly. After replacing that with a proper empty object, the pages in question started working again.

However, I noticed in the installation history that the version I had installed (2018.8.9) was actually 2 behind the latest version that the database knew about (2018.10.0). So I reinstalled (2018.10.0).

Subsequently, I started having the same problems with getting a list of all projects. So I went looking for the same issue again - and didn’t find it. I tried to map the package ids correctly, but after an hour couldn’t figure it out, so I used the API to delete the project.

Now however, I’m concerned about future updates. How can I be sure our next update works as expected?

5

Hi Jeff,

I’m glad to hear that you got yourself unstuck. I apologize for the bad experience you had here, this was a larger upgrade than normal with the introduction of our Spaces feature and I’m sorry that went wrong for you.

In future what I would recommend is performing the upgrade first against a test environment. By that I mean before upgrading your Production instance I would take a backup of you Octopus database, masterkey and on-disk files and restore them into a sandbox environment.

Once that is done perform the upgrade against that environment and perform tests to confirm that everything is OK before scheduling a production upgrade.

If you have any further questions around that process, or anything else I can help with please let me know.

Regards,
Alex