Process Instance Migration: Epic

[danfunk]

PLACEHOLDER for general notes

It should be possible to upgrade a running process instance, in production, to use an updated version of the Process Model.

This is a placeholder for more tasks - but wanted to capture the requirements

• Must function in production
• Allow updates to all "down-stream" changes to the process model - that is activities that would happen in the future
• 1 upgrade at a time is acceptable, though bulk conversions in the future is highly desired
• Ability to save the current instance and revert back to it in the event that the migration fails for some reason
• Migration should be logged - so it is recorded when a migration was applied in the history of events
• Data is preserved - the Timestamps of completed tasks, task data, and data objects

Time Line - Would like to have this completed over the next month (end of June) if at all possible but there is not a definitive timeline.

Issues created to support this epic are:

• Process Instance Migration: Find all completed tasks in a Process Instance SpiffWorkflow#416
• Process Instance Migration: Update the process instance with a new model SpiffWorkflow#417
• Process Instance Migration: Backend and Frontend Changes to execute a process migration #1671

[danfunk]

What is the test that shows this is working?

• Diff the diagrams -

• align tasks based on id

• here are tasks that were added, deleted, modified

• if all changes are after the current token, bulk copy.

• We could limit changes to only work if the token can be moved to a task with the same id in the new model

• We could only allow a migration if no tasks have been added or deleted (only changes within tasks)

How do you assure it's a safe migration?

• Do you test every possible position a process can be in, then migrate it -- can we automate this by running the migration at every point in an existing process-model test.

PreReq:

• Task Data Changes - sprint 30

New Tickets

• Lib: Ability to compare two serialized process models - identify what tasks have changed, which have been added, and which have been deleted. - Sprint 30 - 2.5 days

• Lib: Calculate which tasks were executed in a process instance (climb back up the tree) compare these to what is there. Sprint 30 - .5 days

• Lib: Update the process instance with a new model - and preserve the Task GUID - Sprint 31

• UI Changes to allow applying a migration - 32

• Ability to roll back changes - maybe difficult task 32, 33

[burnettk]

make new instance or update existing?

some feedback from a client:

it could be nice to leave the old one untouched, but as we are talking about having a log of all events separately, I don't think it really makes a difference

Ending up with one process instance with a history that includes a log of the migration event would be super-cool.
I was assuming that we might need/want to spin up a replacement instance with the upgraded process model, but if that's not the case, I wouldn't consider it a requirement to end up with two process instances