Native Locking and Concurrency Management for Deployment Tasks

This topic describes the issues caused by concurrent deployments in Deploy when using custom microservices deployment technologies. Middleware limitations may restrict the target environment to performing only one deployment at a time, leading to potential conflicts.

To handle the above issue, a native locking mechanism is implemented in XLD with locks persisted in DB for example in order to allow a single deployment to be executed.

Users can define a locking policy and/or a concurrency limit for an environment, an infrastructure container, a set of infrastructure containers or a related object (ie locking a cell when deploying to one of its JVM) as shown below.

• A generic locking mechanism is provided for container/CI irrespective of the type of middleware.
• User should be able to lock
  • Container (Infrastructure): Preventing any deployment in that Container irrespective of the environment that shares the same container. (Note: a container can be shared between Environments)
  • Environment: Preventing any further deployment in the same Environment
  • All containers in a given Environment:
    • Preventing further deployment in the same environment
    • Preventing further deployments in any other env that shares one or more containers
  • Deployed Application:
    • Preventing any un-deploy operation
    • Preventing any update deployment

Concurrent update deployments locked when one update is in progress at the same time.

Concurrent undeployments locked when one undeployment is in progress at the same time.

Cleaning up of locks should happen as and when the deployment is complete (FAILED or DONE)

• Force cancel cleans up the locks
• Successful
• Deployment cleans up the locks
• Any database level manual SQL cleanup is accompanied by cleaning up the locks for the tasks being deleted.

Steps

1. Lock infrastructure and the environment with conditions mentioned in Conditions to prevent concurrent deployments.
2. Schedule a deployment.
3. Prior to the scheduled deployment, manually deploy an application and don't finish.
4. Scheduled deployment will be locked till the other deployment cancel or finish.
5. Once the manual deployment gets finished, schedule deployment will resume and finish.

Conditions to prevent concurrent deployments

Concurrent deployments are prevented when the container and environments are select/unselect the Allow Concurrent Deployments with the Lock all containers select/unselect as below:

Container	Environment	Lock All Containers
Unselected	Unselected	Selected
Unselected	Selected	Unselected
Unselected	Selected	Selected
Selected	Unselected	Unselected
Selected	Unselected	Selected

Multiple environments which share the same container

1. Create an infrastructure (Infra1).
2. Create two environments (Env1), (Env2) and add container (Infra1) to it.
3. Lock deployment to Env1 by unselecting 'Allow Concurrent. Deployments' in infrastructure (Infra1) and environment (Env1) and selecting 'Lock All Containers'.
4. Deploy two applications to the environment (Env1) at a time, the lock will be obtained for concurrency.
5. Allow concurrency for Env2 and un-select 'Lock All Containers' option.
6. Deploy two applications to the environment (Env2) at a time.
7. Since lock is enabled in Env1 the concurrent deployment will be locked irrespective of lock configuration in Env2.

Retry

1. Enable lock retry in environments.
2. Set 'Lock retry interval'.
3. Set 'Lock retry attempts'.
4. Set lock for environment and infrastructure.
5. Schedule a deployment.
6. Prior to that manually deploy an application and do not finish.
7. Scheduled deployment will be executing till the number of attempts set in step3 'Lock retry attempts'.
8. The retry attempts will be run every time based on the time set in step2 'Lock retry interval'.
9. When manually deployed application is finished, the retry attempt will be stopped and deployment will be success.