Deployment has the following phases:
The following sections describe these phases, and the JMS messages that the DeploymentManager
sends to coordinate each phase across multiple deployment servers.
Deployment Start
When a call to the deploy()
method of the DeploymentManager
is received, the following actions occur:
The
DeploymentManager
sends aSTART_DEPLOYMENT
message. No deployment engine processing occurs at this point; the message exists principally to allow custom integration with the deployment system.Note: if another deployment is in progress when the call to the
deploy()
method is received, the second deployment is queued.A thread is spawned that manages the remaining deployment process. This thread is the main or management thread; there is only one instance, and it resides on the calling machine.
Control returns to the caller. The
DeploymentData
objects that are passed into thedeploy()
method are retained by the management thread. They should not be altered by any client code.In the management thread, the
DeploymentManager
writesDeploymentData
andMarkers
to the deployment repository. This process is controlled by theDeploymentManager
where thedeploy()
call was made.To write the data efficiently to the deployment repository, the
DeploymentManager
spawns no more thanmaxThreadCount
number of worker threads, assigning each threadDeploymentData
andMarker
objects up to a maximum ofthreadBatchSize
.Before starting the worker threads, the
DeploymentManager
sends aMARKER_PERSISTENCE
message.
Pre-Deployment
After the threadBatchSize
number of Marker
objects are written, deployment enters the pre-deployment phase. With a full deployment, all repository items are deleted during this phase from the target repositories. Depending on the configuration (specifically, when the /atg/deployment/file/DeploymentConfiguration.noVerificationByChecksum
option is enabled), all files can also be deleted from the target virtual file systems.
When this phase is complete, the DeploymentManager
sends an ADD_UPDATE_PHASE
message that triggers the start of the Add/Update phase.
Add/Update
This phase begins when an ADD_UPDATE_PHASE
message is sent to a deployment-specific JMS topic. The message contains the ID of the deployment associated with the message. Instances of the DeploymentManager
on each server are subscribed to that topic and begin processing on receipt of this message; this includes the DeploymentManager
component on the server that manages the deployment process.
During this phase, the following actions occur:
All repository items whose action property value is
add
orupdate
are created.All properties with primitive types are set on items whose action is
add
orupdate
.Properties of repository items that are required references are set to a temporary dummy item. Only one dummy item of each referenced item descriptor is created; these are deleted at the end of the deployment.
Properties marked as
deployable=false
are not deployed.Files whose action is
add
orupdate
are copied to the responsible deployment agents.
When these actions are complete, the Marker
item status is set to ADD_UPDATE_COMMITTED
.
If an error occurs, the current transaction is rolled back. In a separate transaction, the Marker
status for the item that failed in the current batch is set to FAILURE
. The deployment’s failureCount
property is incremented, and the Marker
is removed from the worker thread’s list of items to operate on. The transaction is restarted from the beginning, skipping the item that failed. When the failureCount
is greater than the maxFailureCount
property configured in the DeploymentManager
, the entire deployment fails.
After the management thread determines that the status of all Markers
is ADD_UPDATE_COMMITTED
, it starts the next deployment phase.
Reference Resolution
During this phase, all repository items with an action of add
or update
that contain references to other items, either a single reference or a collection of references, are resolved. To start this phase, the management thread sends a REFERENCE_UPDATE_PHASE
message to the deployment-specific JMS topic. As in the first phase, each DeploymentManager
starts all its threads and begins querying the deployment repository for work.
At the end of this phase, each Marker
that has been processed has its status changed to REFERENCES_COMMITTED
. Any Marker
whose action is delete
also has its status changed to REFERENCES_COMMITTED
.
For file assets, this deployment phase is ignored.
Delete
This phase starts when the management thread sends a DELETE_PHASE
message. All worker threads are started, and each one requests a series of Markers
to process. In this phase, only Markers
whose action is delete
are processed. For those, the specified items are deleted from their repository. If an error occurs, the transaction is rolled back and all Marker
statuses are set to FAILURE.
When all deletions are complete, control returns to the management thread, which sets the deployment’s status field to DATA_DEPLOYMENT_COMPLETE
.
Destination Synchronization
During this phase, all destination repositories are synchronized by invalidating the caches for all the repositories on the target instances.
Note: For large file deployments in certain configurations (when the /atg/deployment/file/
option is disabled, or on the second apply phase of a switched deployment when ATG Content Administration is being used), operations that occur on the target can be time consuming.
DeploymentConfiguration.noVerificationByChecksum
Deployment Completion
The management thread sets the status of the deployment to DEPLOYMENT_COMPLETE
and sends a COMPLETE_DEPLOYMENT
message to all the DeploymentManager
components. If the purgeDeploymentData
flag is true in the deployment repository item, the Marker
and deploymentData
items are removed from the repository before the status is set.