Updating App versions - deployment tips
Do you have any tips for the best way to deploy new versions of Apps?
Change management can be a bit ad hoc sometimes and I'd like to know what experienced users usually do to maintain their services while updating their systems.
For example, is it possible to update existing processes that were started before an App update, so that they use the new App version instead of the old one? Is there any potential disruption that can be caused by updating and App while there are already processes running?
-
正式なコメント
Thank you for your inquiry regarding the deployment of new App versions in Questetra BPM Suite.
Questetra BPM Suite has a versioning model designed specifically to make change management safe and predictable, even while Processes are running. Here is a summary of how it works, together with some tips commonly used by experienced App administrators.
1. Impact on in-progress Processes when a new version is released
When you modify an App and click [Release developing version], a new version number is automatically assigned. However, any Process that was already started before the release will continue to flow according to the definition at the time the Process was started — the old version. Only Processes started after the release will use the new definition.
As a result, in most cases releasing a new version does not disrupt running Processes. You can safely update flow logic, add/remove steps, modify Script Tasks, or adjust Operator rules without affecting cases that are already in flight.
For reference, this is explicitly documented here:
M201: Run the Defined Business Process as a Workflow System
M318: Controlling External Access to the Message Catch Event API
2. Can existing Processes be migrated to the new App version?
No — by design, in-progress Processes cannot be "switched over" to a newer version. This is to guarantee audit integrity: each case records the exact definition it ran under at the moment it was started.
If you need newly-released changes to apply to existing work, the typical approaches are:
Wait for in-progress Processes to complete, then all subsequent starts will naturally use the new version.
If you must phase out legacy cases sooner, you can [Suspend] the App, which offers an option to terminate all Processes in progress at once. Use with care — terminated Processes cannot be resumed.
If the new version represents a major redesign, some teams prefer to [Copy] the App and operate it as a separate App in parallel, directing new work to the new App while the old App finishes any remaining cases. Note that Process data (business records) is not duplicated when an App is copied.
3. Recommended change management practices
The following are commonly used to keep releases smooth:
Use [Debug process execution] on the developing version before releasing. You can run test Issues without a Release, and the "Allocate all tasks to me" option lets a single designer walk through every Step. See: How Do I Conduct Operational Tests on a Running Workflow App? and How to Ensure Apps Operate Correctly. (Note: Debug Processes are automatically deleted when a new version is released, so release only when debug traffic has been cleared.) Leave a Version Note at release time. This is stored on the App properties and is very helpful for later auditing.
See R2011: Properties of Workflow App. Use Profiles and Variables so that test runs can point to staging endpoints/email addresses, and production runs point to real ones — without editing the App each time.
Rely on automatic snapshots. Every edit creates a snapshot, and you can revert the developing version to the latest released version or any earlier snapshot if something goes wrong mid-edit.
Export as a QAR file before large changes. You can export the current state as an App Archive (QAR), giving you an off-platform backup you can re-import if needed. See R2014: App Archive Specifications and Information Contained in App Archive (QAR).
Avoid simultaneous editing. Concurrent editing of the same App by multiple users is not supported (the latest [Save] wins). Coordinate edits within your team.
Release small, release often. Because in-progress Processes are not affected, incremental releases are typically safer and easier to review than rare large ones.
Please let us know if you have a specific scenario (for example, a Script change that needs to apply retroactively, or coordinating updates across connected Apps) — we would be happy to suggest a more tailored approach. Best regards, Questetra Support
コメントアクション
サインインしてコメントを残してください。
コメント
1件のコメント