Newborn
At some point in developing your Axon Ivy Project, you’ll bring it to life by deploying it to an Axon Ivy Engine. That’s when your beautifully designed processes start running and make life easier for everyone. If your project is the very first one deployed on the engine, everything is straightforward.
Time flies
But time flies, requirements change, and sooner or later you’ll need to update your process - your Axon Ivy Project. And that’s where things can get complicated. Should you deploy a new version (a Process Model Version) of your project, or should you override the existing one? What happens to dependent projects that build on yours?
Deploying a new Process Model Version is usually the safer choice. It ensures that running cases can finish in their original version while new cases start in the latest one. However, after several months of updates, you might find yourself with ten different versions of the same project - all still active with running cases.
World is ending
Then one day, a critical issue appears. The Axon Ivy Engine needs to be restarted daily because its memory usage keeps growing. After investigating, you discover a memory leak in a piece of Java code that was triggered only recently due to a rare condition in a Split Gateway. You quickly fix the issue in the latest process model version - but what about the other nine versions still running? Yes, you have to fix those too. And that’s a nightmare.
Good - you’re done! You’ve just completed the tedious job of fixing all nine running project versions. Now it’s time to deploy them. With each deployment, you need to carefully target the correct Process Model Version, hoping that nothing breaks in the process - because how these versions are interconnected is a well-kept secret buried deep inside Ivy’s codebase.
But...
You’re a careful developer and have thoroughly tested all your fixes in your test environment. Then comes day X - the planned deployment to production, approved and scheduled with management. But suddenly, the deployment fails. Why?
It worked perfectly in your test system! The reason lies in the validations performed during deployment. These checks depend on runtime data, which can vary subtly between environments - and those differences can make all the difference.
Root Cause
The complexity for the Axon Ivy Engine is enormous - every corner case must be handled precisely, with well-defined cache invalidations, to avoid the need for restarting the Axon Ivy Engine after each deployment. For instance, every Process Model Version maintains its own Classloader, which adds another layer of intricacy.
