We're about to go into controlled production on the current Activiti version (5.5). What can we expect wrt upgrading an installation (containing live customer data) without impacting that customer's workflows? I did see some discussion in another topic (http://forums.activiti.org/en/viewtopic.php?f=6&t=1138&p=4615&hilit=database+upgrades#p4615), but it's not clear what the intended approach is in the near and longer term.
upon boot, by default (override with configuration) Activiti checks if the database schema is in sync with the library used. if not, an automatic upgrade is performed. all your data will be maintained during those upgrades. but we only have limited coverage of these upgrade procedures so it's always good to perform a backup with database specific tools before upgrading the library in production.
the sourcecode and library contains the upgrade scripts. @see eg /activiti-engine/src/main/resources/org/activiti/db/upgrade/activiti.h2.upgradestep.54.to.55.engine.sql you can review them in advance if you want.
in the 5.6 upgrade, there will be a known limitation (still all data will be preserved):
Known upgrade limitation
In the DB schema creation scripts, we've enlarged the max size of certain varchar columns from 255 to 4000. See ACT-236. These schema updates are not part of the automatic upgrade procedure.
Max length of following columns has been set to 4000:
ACT_RU_JOB.EXCEPTION_MSG_ ACT_RU_JOB.HANDLER_CFG_ ACT_RE_PROCDEF.RESOURCE_NAME_ ACT_RE_PROCDEF.DGRM_RESOURCE_NAME_ ACT_RU_TASK.DESCRIPTION_ ACT_RU_VARIABLE.TEXT_ ACT_RU_VARIABLE.TEXT2_ ACT_HI_TASKINST.DESCRIPTION_ ACT_HI_TASKINST.DELETE_REASON_ ACT_HI_DETAIL.TEXT_ ACT_HI_DETAIL.TEXT2_ ACT_HI_COMMENT.MESSAGE_ ACT_HI_ATTACHMENT.DESCRIPTION_ ACT_HI_ATTACHMENT.URL_ If you want to perform these changes, you can do that manually. Check your database capabilities for the easiest way on changing the type of columns from varchar(255) to varchar(4000). As a fall back, for each table affected, you can:
create a new temporary table copy the contents from the original to the temporary table delete the original table recreate the original table using the new create script with the proper lengths copy the contents from the temporary table back to the new original table drop the temporary table
