The Deployment model allows you to define the model versions and database upgrade scripts between those versions.

Deployment scripts will get executed when you deploy a new version to the customer.

You will typically use the Deployment Script Generator for data model deployment scripts.

Resolving the Deployment Order

The order in which the individual deployment versions run is simple if you only have one package. The deployment versions contained in the package will run in the order determined by their version number.
The deployment order will get more complicated as you add more packages and more deployment versions.


Let’s say you have package A in your project and you create deployment versions 1.0 and 1.1. Later you add package B and create deployment version 1.0 of that package. Then you create version 1.2 of package A. When you deploy your project into an empty database the deployment versions will run in this order: A1.0, A1.1, B1.0, A1.2. The fact that you created the B1.0 when there was another package called A and it was in version 1.1 is noted in the deployment file and this dependency will be respected.

Deployment Deadlocks

There may be situations when the deployment order cannot be established. Now we will look at how can such a situation develop. First we create a project with Root and Security packages inside. Then we add A package.

Root Security A
5.1.9 5.3.1

Then we notice we made a mistake. The Security’s latest version is 5.3.2, not 5.3.1. So we update the Security package. Now we have a problem because the version 5.3.2 of the Security package depends on version 5.1.8 of the Root package. So we have this:

Now there is a problem when the deployment runs. Nothing can be deployed once the Root 5.1.8. and Security 5.3.1 are deployed.

  • A 1.0 cannot run because Root 5.1.9 is not deployed yet
  • Serurity 5.3.2 canot run because it has to wait for A 1.0
  • Root 5.1.9 cannot run because it has to wait for Security 5.3.2

You will get a message simillar to this

Deployment script order could not be determined, because circular dependencies were detected among some deployment versions.
Successfully ordered deployment versions:
Root 0.10
Root 0.20
Root 0.30
Root 0.39
Root 1.1
Root 4.0
Serurity 5.3.0
Serurity 5.3.1
The sorting process failed with these deployment versions as the next step candidates:
Candidate: Root 5.1.9
		Root 5.1.8
Candidate: Security 5.3.2
		Root  5.1.8
		Security 5.3.1
Candidate: A 1.0
		Root  5.1.9
		Security  5.3.1

The problem cannot be fixed in the Architect yet. You have to open file of the deployment version A 1.0 and change the dependency from Security 5.3.1 to 5.3.2 in the deploymentDependenciesCsv element.

    dv:deploymentDependenciesCsv="&#xD;&#xA;147fa70d-6519-4393-b5d0-87931f9fd609, 5.1.8&#xD;&#xA;951f2cda-2867-4b99-8824-071fa8749ead, 5.3.1"