Our question is: what do other Flowable customers typically do if they need to revert to an older release? Do they maintain custom revert scripts? Or simply restore database backups?
For context:
We’re running on PostgreSQL.
The service is deployed across multiple environments (~70–80 services, each with its own DB).
Manual changes (like dropping columns or foreign keys) are not really feasible at this scale.
Right now, we’re debating whether to:
Prepare custom Liquibase changes for reverts, or
Create temporary database backups for rollback purposes.
Is there a recommended approach from Flowable for this scenario?
Thanks in advance for your guidance!
What we advise to all Flowable users, regardless of commercial or not, is to create a database backup at minimum when doing an upgrade. Whatever happens, that is always a good idea. Additionally, having a set of smoke tests executed on a dev env first is of course proper engineering practice.
What you are asking for is that every DB change has a counterpart to ‘undo’. While conceptually that might work, it’s not always striaghtforward to do. For example, imagine that you’re running a process and use new features, that are also stored in the audit tables.
If now a rollback is required later on, what should happen with the data stored in the new features? Removing is not always possible, e.g. with compliance regulations in place. And what if then after the rollback, the new version or a patched version is put back? Then those instances could be in a state that is ‘incorrect’ from an audit perspective.
While technically we could support rolling back and forwards, there are business implications associated to it, as processes often contain valuable business information. Anyway, the above is a bit to give context around the answer of database backups, hope it helps
We see one practical issue with relying only on database backups for rollback.
By “backup” we mean the full database, including all Flowable tables. If we restore such a backup, it would also restore the state of running processes as they existed at the backup time. This means some process instances in ACT_RU_* tables would resume execution — and in our case (where Flowable orchestrates Cloud Foundry application deployments), this could unintentionally trigger actions like deleting or redeploying applications.
An alternative would be to back up only our business tables and clear the Flowable tables on rollback. However, that would terminate all running processes, which is also not feasible since processes run continuously.
You mentioned that rolling back schema changes can be problematic because of new features or data stored in audit tables.
Wouldn’t a full database restore face a similar issue, since it also removes data introduced after the backup was taken?
We understand some inconsistency in audit data might occur when reverting to an older version, but this risk exists both with a backup restore and a Liquibase-based rollback.
In our opinion, if minor Flowable versions maintained some degree of backward compatibility, it would be easier to apply targeted Liquibase changes even if some audit inconsistencies occurred. As long as the process instances could continue running after a revert, that would be the ideal scenario for us. In other words, having the older Flowable version remain compatible with the database schema of the newer one (within a minor version range) would simplify rollbacks significantly.
It would, but the data would not be in a corrupted state. There’s a reset of state, that is true. In reality, we’ve seen customers taking a snapshot of the database before rolling back and then replaying things. But this is of course in different contexts than what you’re working with here, where you’ve got applications being deployed or undeployed as a side-effect.
In general, that’s what we’ve been doing - but I guess the difference here is that for us 7.1.0 to 7.2.0 is not a minor upgrade. E.g. 7.2.0 to 7.2.1 would be.
Would it be possible to maintain backward compatibility between consecutive minor versions as well — for example, between 7.2.0 and 7.3.0, not just between patch versions like 7.2.0 and 7.2.1?
This would make it much easier for users to safely revert after an upgrade.
To clarify, we’re mainly thinking about compatibility only between +1 minor versions (e.g., 7.2.0 ↔ 7.3.0), not across larger version gaps.
Is that something you might consider for future releases?
While we strive to limit the changes to the database as much as possible for any type of release, what you are asking is to change our complete versioning schema, which is not something we would do overnight.
To clarify: we’ve had the 7.x line for a long time now, and as you can read in Flowable 7.2.0 release we’re now working on a 8.x, mainly because the upcoming Spring/Jackson changes. So this is really a discussion about version numbers, i.e. for us a 7.x.a → 7.x.b is a minor change, while changing the x is a major one. Changing the 7 to 8 means a major change, e.g. a new engine architecture (the 5 –> 6 for example), or changes that have a huge impact potentially (e.g. the 7 –> 8).
