Are you a customer of Octopus Deploy? Don't raise the issue here. Please contact our support team so we can triage your feature request, making sure it's handled appropriately.
We're on a journey to better normalize Octopus's database schema. Doing so will unlock the ability to solve many known performance and concurrency issues.
We initially thought we could achieve a good deal of this normalization using our current ORM, Nevermore.
As we dug into the problem with a team, we found problems we'd need to solve in Nevermore to use it as the tool to meet our normalization needs. This was particularly an issue for loading and querying data across multiple database tables that might back a single logical model.
The team then evaluated the cost of solving these problems in Nevermore against the cost of migrating to a tool that could already do these things, like Entity Framework.
Moving to Entity Framework was already in our plans, as we want to use commodity tools for most common things. However, we originally thought we could delay the cost of the migration to achieve our more immediate goals sooner.
After we disproved this assumption, we realized moving to Entity Framework sooner was the better option. We updated the target architecture accordingly, and we're now deep into the work of moving ORMs in the core of Octopus.
Are you a customer of Octopus Deploy? Don't raise the issue here. Please contact our support team so we can triage your feature request, making sure it's handled appropriately.
The Need
From Target Architecture Blog Post:
Solution
Convert
RunbookProcess
to use Entity Framework.Links
Target Architecture Blog Post