The purpose of a deploy request is to indicate that a policyRules Engine: Refers to a read-only version of a set of rules that identify requests and the set of actions that can be applied to them. A policy may be applied to either the Staging or Production environment. is ready to be applied to either the Staging or Production environment. Once a deploy request has been submitted, it will undergo an automated validation and error detection system. If no issues are detected, then the policy will be applied to the requested environment.
Although most rules may undergo automated validation, more complex rules require manual review. This manual review process may take up to 4 hours.
It may take up to an hour before a policy is fully deployed to the Production environment, while deployment to the Staging environment should only take approximately 15 minutes.
The submission of a deploy request may be initiated when viewing a policy. This submission process requires the selection of a target environment (i.e., Staging or Production) and a description of the deploy request.
Please try to assign a relevant description when submitting a deploy request. This information may prove to be helpful when reviewing deploy request history.
Two simultaneous deploy requests to the same environment may not be submitted. Please wait until the previous deploy request has been deployed, rejected, or canceled before submitting another deploy request.
Upon selecting the desired environment, the XML differences between the new policy and the one currently deployed to that environment will be displayed. Review the XML changes to validate that the policy accurately reflects the configuration that should be deployed to that environment.
Learn how to interpret XML data.
The following table describes how XML changes are annotated.
Change Type | Line Color | Description |
---|---|---|
New Line (Addition) |
Green |
Indicates that the new policy contains a line that is not present in the policy currently deployed to the requested environment. |
Deleted Line (Deletion) |
Red |
Indicates that the new policy does not contain a line that is present in the policy currently deployed to the requested environment. |
No Change |
White |
Indicates that the line is present in both policies and no changes were detected. |
A change in a match condition or feature's setting is reported as:
The following illustration demonstrates a change in the Compress File Types feature's media type from "text/html" to "text/htm."
A deploy request must undergo a review and approval process before a policy may be applied to the Staging or Production environment. The workflow for core deploy request states is depicted below.
A description is provided for each deploy request state below.
State | Description |
---|---|
Submitted |
Indicates that a deploy request was submitted by a user. |
Canceled |
Indicates that the deploy request was canceled by a user. This state will also be applied to a deploy request upon multiple unsuccessful retry attempts. |
Pending Review |
Indicates that the deploy request is awaiting manual review. Manual review is required when the logic in a deploy request could not be automatically approved by our automated policy review system. |
Escalated |
Indicates that the deploy request was escalated after manual review. This state only applies to deploy requests for complex policies. As a result, most deploy requests will bypass this state. |
Rejected |
Indicates that the deploy request was rejected and the corresponding policy will not be applied to the target environment. A message will indicate the reason why the deploy request was rejected. Duplicate the corresponding policy and then adjust the configuration accordingly. |
Verification Delayed |
Indicates that the deploy request contains logic that is indicative of an invalid configuration. Although you can resubmit the deploy request by viewing it and then clicking Retry Deploy Request, the recommended procedure is to cancel the deploy request, duplicate the policy, review/revise all rules, and submit another deploy request. |
Deployment Delayed |
Indicates that the deploy request contains logic that is indicative of an invalid configuration. Although you can resubmit the deploy request by viewing it and then clicking Retry Deploy Request, the recommended procedure is to cancel the deploy request, duplicate the policy, review/revise all rules, and submit another deploy request. |
Approved |
Indicates that the deploy request has been approved for deployment. |
Deployed |
This state is applicable while a policy is being deployed to either the Staging or the Production environment. It may take up to an hour before a policy is fully deployed to the Production environment, while deployment to the Staging environment should only take approximately 15 minutes. |
The last status assigned to each deploy request is indicated on the Deploy Requests section of the Rules Engine page. Clicking on the desired deploy request will display its historical status activity.
The policy currently deployed to both Production and Staging environments are indicated in the Production and Staging sections of the Rules Engine page. Additionally, historical status activity for the corresponding deploy request may be viewed by following the "View deploy request" link that appears below the policy name.
Deploy request history is displayed under the Deploy Requests section of the Rules Engine page.
Click on a deploy request to view:
An email notification may be sent whenever a deploy request enters a new state.
Key information:
An email notification may be sent to one or more email addresses. Use a comma to delimit each email address.
Sample configuration:
The following syntax will be applied to the subject line for each email notification:
To set up deploy request state notifications