Transactional Deployment & Rollback Strategy

Introduction

One of the key things that are a top priority in the development of Configuration Manager is to guarantee the target system's consistency after a snapshot deployment. To achieve this CMJ needs to properly handle any situation, e.g. if an unexpected error occurs, and make sure either the whole configuration was deployed or none of it in a transactional manner.

In version 3.6 CMJ introduced a custom roll-back strategy in case a snapshot deployment fails.

The problem

Until version 3.5.x CMJ relied on Jira's native transactions to rollback the uncommitted changes and all changes from deployment were performed within a single transaction. However, this leads to several major problems for larger deployments:

• Jira's internal configuration caches are not transaction aware and are not automatically updated when configuration objects are added and other configuration changes depend on it. We worked around this problem by doing on-demand cache refreshes in case of a lookup failure. For more information review this issue - https://jira.atlassian.com/browse/JRA-38550

• Jira doesn't officially support configuration changes from within a transaction. Since Jira 7.x the cache refreshes are performed using a new DB connection and there is no way to use newly added configuration objects from within the same transaction. For more information - https://jira.atlassian.com/browse/JRA-59733

The solution

CMJ implements a rollback strategy that will revert all configuration changes in the case of an error and leave the system in the initial state (before the deployment was started).