Deployments

Internal deployment are built & executed internally as part of any operation which relies on changes being loaded or unloaded during development (i.e. switching branches).

Schema Evolution

While it isn't possible in all scenarios, internal deployments will generally load changes into the latest schema version, before re-organizing & transitioning once at the end of the deployment.

To avoid conflicts between development & deployment, JADE IDE functions used to version & re-org schemas are blocked while there's an internal deployment outstanding. Conversely, an internal deployment cannot be built & executed while there's an outstanding schema re-org which wasn't caused by JadeGit.

Deployment Control

Following a deployment failure (which may be due to external factors like disk space, or due to an unsupported scenario), the deployment can be retried or aborted via the repository context menu.

Retry

Restarts the deployment from the last command which failed. This prevents problems which can arise when commands are repeated.

When a deployment has failed due to a command error (i.e. entity cannot be removed due to references), the deployment can be recovered by disabling JadeGit temporarily to amend the related entities as required for the subsequent retry to succeed.

Abort

Attempts to undo the deployment commands which have already been executed (deleting the deployment if successful).

Provided there's been no re-org performed, nor changes loaded into the current schema version, then it should be able to roll back to a known state.

If a re-org has already been performed, or changes loaded into the current schema version, the repository will be left in an unknown state. To recover, the repository reset function needs to be used, which attempts to reload the complete schema definitions.