Application Deployment Policies on the Platform allow Platform Operators to set specific rules governing the deployment of guest applications and application components to target servers. These policies apply comparison logic set by the Platform Operator to match specific characteristics of Platform objects (like application components or Resource Policies) with the properties of servers and database nodes to filter deployment targets.
An Application Deployment Policy, when defined as Active, is applied each time an application component to which it is assigned is deployed on the Platform. You can view, manage, and delete Application Deployment Policies on the Configuration> Application Deployment Policies page in the SOC.
Note: Application Deployment Policies created by the Platform Operator may affect the deployment of Platform components required for normal Platform operation. Before making changes, you should understand how Application Deployment Policies affect Platform behavior. See more about sever requirements for Platform components.
To create a new policy, click the New Application Deployment Policy button in the upper right. This will open a New Application Deployment Policy window:
In this window,
When you have configured the General Settings, click Next. This will open the Source Object selection window:
Here, you are asked to choose a Source Object and Source Property for the policy.
A Source Object is either a component that can be deployed, or an object associated with deployable components:
Depending on what you have selected as your Source Object, choose the Source Property you’d like to to associate with the policy. This property is used in the policy’s comparison logic when choosing a deployment target. If either Applications, Resource Policies, or Storage Quotas is selected as the Source Object, these Source Property choices that are available:
|Source Object: Applications, Resource Policies or Storage Quotas|
|Deployment Team Alias||Compares the alias of the Development Team associated with the Source Object involved in deployment to the DevelopmentTeamAlias tag of target servers and database nodes|
|Authentication, Authorization, or Multi-tenancy||The specific Application Services Level, if it is set for the application associated with the component being deployed or if the Resource Policy/Storage Quota associated with the component being deployed is tagged with that Application Service, is used to compare to that specific Application Service property tag for target servers and database nodes|
Note: Depending on the Platform’s Custom Properties configuration, additional Source Properties may appear in this dropdown list. Platform Operators have the ability to create Custom Properties applied to the Platform objects referenced in the deployment policy creation process. If a Custom Property is configured to apply to the Source Object chosen in the dropdown list, that Custom Property will appear as an option in the Source Property list and be used in the deployment policy’s comparison logic.
If either User Interfaces, Services, Windows Services, Java Web Applications, or Databases is selected as the Source Object, these Source Property choices will be available:
|Source Object: User Interfaces, Services, Windows Services, Java Web Applications, or Databases|
|DeploymentStage||The policy will use the Deployment Stage (either "Sandbox" or "Published") of the application associated with the component type being deployed to compare to the DeploymentStage property tag for target servers and database nodes|
Just as with the previous Source Object choices, depending on the Platform’s Custom Properties configuration, additional Custom Properties may appear in this dropdown list as well.
Once the Source Object and corresponding Source Property have been defined, click Next. This will open the Comparison Logic definition window:
This window allows you to define Comparison Logic that the deployment policy will use to evaluate the Source Property of the selected Object against the corresponding Source Property of potential deployment targets. You can stipulate that the Property setting of the Source Object Contain Any, Not Contain Any, Contain All, or Not Contain All of the properties of the target servers. The table below outlines how each Comparison Logic works:
|Description||Contain Any||Not Contain Any||Contain All||Not Contain All|
|A||A||Exact match||Deploys||Does not deploy||Deploys||Does not deploy|
|A||A,B||Full match on App||Deploys||Does not deploy||Does not deploy||Deploys|
|A||B||No match||Does not deploy||Deploys||Does not deploy||Deploys|
|A,B||A||Full match on Policy||Deploys||Does not deploy||Deploys||Does not deploy|
|A,B||B,C||Partial match||Deploys||Does not deploy||Does not deploy||Deploys|
|A||<none>||No match||Does not deploy||Deploys||Does not deploy||Deploys|
|<none>||A||No match||Does not deploy||Deploys||Does not deploy||Deploys|
|<none>||<none>||Exact match||Deploys||Does not deploy||Deploys||Does not deploy|
You also must indicate whether the Comparison Logic Must or Should be met in order for component deployment to succeed:
Once the settings are complete, click Next again to see a summary of the deployment policy describing the policy’s Evaluation Logic. After reviewing the summary, click Finish to create the deployment policy. After the policy is created, it will appear on the Application Deployment Policies list, along with information about the policy’s Evaluation Logic, the application Deployment Stage(s) that the policy applies to, and an indication of whether or not the policy is active:
You can update a policy by clicking the corresponding Edit button to the right. To delete a policy, choose the Delete option from the dropdown menu to the right of the Edit button.
The ordering of Application Deployment Policies on this list is important, since it reflects the order in the polices are applied when the Platform makes deployment decisions. All policies containing Must in their Evaluation Logic appear at the top of the list, since it’s necessary for their conditions to be met for deployment to happen at all.
Should policies, however, allow deployment even if their conditions are not met, so the order in which they are applied will affect which deployment target is chosen. The Should polices higher on the list are applied before those lower on the list. If no deployment targets meet a “Should” policy’s criteria, that policy is ignored, and the next policy on the list is applied. The process of applying ordered Should processes continues until either the list of deployment targets has been narrowed down to a single target, or until all policies have been applied, in which case the Platform will choose a deployment target from the remaining server targets.
To change the order in which the Should policies are applied, drag and drop the policy to the preferred spot on the list (keep in mind, a Should policy cannot be above any of the “Must” policies). Also, although policies are applied in the order that they appear on the list, policies marked as “Inactive” are not applied, regardless of their ordering.
Platform Operators can manually deploy new workloads or move existing workloads from an Application’s Details page. When deploying a new or moving an existing workload from that page, the Platform Operator can choose the server where the workload will deploy, or let the Platform decide using Deployment Polices. If the Platform Operator chooses a server manually, the Platform will deployed the workload to the selected server without applying any Deployment Policies.
Manually choosing a server for a new workload deployment will also create a Platform Operator Override that could affect workload instance counts on the Platform until the override is removed. Read more about creating and managing Platform Operator Overrides.