Validate an edition
Validating an edition is the process of determining if a new edition is available and ready to move into production and replace the current edition. We can install and validate a new edition under realistic conditions while the production application edition continues to serve requests.
- Ensure that all of the modules for the application are deployed to the same deployment targets.
- Define unique routing rules for edition 2.0.
Routing rules enable editions to run concurrently and hypertext transfer protocol (HTTP) requests for the validation edition to correctly route to the validation target without interfering with edition 1.0. For this scenario, use the my_application application. Install both application editions, 1.0 and 2.0, on the dynamic_cluster_1 dynamic cluster. routing policies for application editions.
- To set the operational mode of the cloned validation cluster to a different mode from the production cluster, create the VALIDATION_OPERATIONALMODE custom property in the administrative console. Otherwise, the validation cluster is set to the same operational mode as the production cluster after it is created. Set the value to automatic, manual, or supervised. If we specify any other value or we do not specify a value, the validation dynamic cluster is set to manual mode.
Restriction: Only two cluster members can be used or created in validation mode. We can map routing and service policies to the validation mode application, but no more than two cluster members are started to maintain the work. We can overwrite this setting after the validation cluster is created by changing the minimum and maximum number of dynamic cluster instances.
- If we are a user with either a monitor or an operator role, then we can only view the application edition manager information. If we have the role of configurator or administrator, then we have all the configuration privileges for the application edition manager.
Restart the browser before validating an edition. By restarting the browser, you ensure that previous sessions expired, and that the requests are routed to the application under validation.
Ensure that the application being validated is not deployed to a webserver, as it may cause the validation to fail. Applications need to be deployed to application servers for proper validation.
Consider the following scenario as an example of how validation is performed on an edition: Edition 1.0 of an application is installed, active, and running on a dynamic cluster. Edition 2.0 is the candidate validation edition and is installed on the same deployment target in the inactive state. Validating edition 2.0 clones the edition 2.0 deployment target. For example, the validation might create a new dynamic cluster, such as the DC-Validation dynamic cluster, and map edition 2.0 to this new cluster. The cloned cluster uses the existing cluster members as the server template for the creation of the cloned servers.
After the validation clone target is created, edition 2.0 is activated, and the routing rules are defined, we can start, stop, and reconfigure the edition.
Validate an edition
- Verify that the application has two installed editions, with only one active edition.
-
Applications > Edition control center
- To create a validation cluster that has a different operational mode than the production cluster, we can define the VALIDATION_OPERATIONALMODE custom property on the production cluster.
Add the validation cluster to the service integration bus (SIB). If we do not define this custom property, our validation cluster has the same operational mode as the production cluster.
- Update the EJB reference bindings to specify the new cluster name. Before rolling out the application from the validation cluster, the bindings must be changed back to the original value.
- Click my_application application.
- Select edition 2.0 and click Validate.
The validation status page shows each validation step and deployment of edition 2.0 to the cloned cluster. When complete, The application edition control center shows that one of the editions is in validation mode, and the manage editions page shows that the edition 2.0 target is now the dynamic cluster...
-
dynamic_cluster_1-Validation
The dynamic cluster page shows that the dynamic_cluster_1-Validation dynamic cluster is created, and the servers page shows the cloned servers.
Tip: To save the validation cluster after performing the rollout, we can create the saveClonedCluster custom property on the validation cluster. Otherwise, the validation target is deleted after the edition rollout or after the validation is canceled for all of the applications on the validation target. For example, if we have two applications deployed to the validation target, and one of the applications is validated and rolled out, the validation target is not deleted until the second application is validated. The saveClonedCluster custom property applies only to dynamic clusters.
- Verify that the validation occurred correctly...
-
Applications > Enterprise applications or Applications > All applications
Edit the my_application-edition2.0 application.
- For PHP and WebSphere Application Server Community Edition applications:
Verify that the context root, deployment targets, and so on are pointing to the cloned cluster.
- For enterprise (Java EE) applications:
Select Manage modules. Verify that edition 2.0 is mapped to the validation cluster. From the Map EJB references to beans detail view, verify that the Java Naming and Directory Interface name is adjusted for the new cloned target name.
For an application edition with fully qualified bindings based on the original deployment target name to operate correctly on a validation deployment target, change its binding names to reflect the fully qualified binding names based on the validation deployment target name. For example, an application with a resource reference bound to...
-
/clusters/clusterb1/jdbc/CustomerData
...must have the binding changed to...
-
/clusters/cluster1-validation/jdbc/CustomerData
...as the application is prepared to run on the deployment target clone.
- For PHP and WebSphere Application Server Community Edition applications:
- Navigate and review the validation cluster - creation details
Dynamic Clusters > DC_Name > Config tab
Note the following settings are copied over for the validation cluster:
- Minimum number of cluster instances
- Vertical stacking of instances on the node
- Membership policy
Take note of the following details:
- Maximum number of cluster instances is set to "2". This is a restriction to validation clusters.
- Isolation preference is not copied, but set to the default.
- Operational mode is copied, but can be overridden by the VALIDATION_OPERATIONALMODE custom property.
- No custom properties of dynamic clusters is copied over to the validation cluster.
Custom properties of the production cluster are not propagated to the validation cluster. Any custom property of the dynamic cluster, if needed, should be set after the validation cluster is created.
- Test the new edition.
Start the validation cluster, and with your routing rules in place, try sending a request load to the edition 2.0 edition to test the edition. The edition 1.0 edition remains in production.
What to do next
If we successfully complete the edition 2.0 edition testing, we can replace the edition 1.0 edition with the edition 2.0 edition. If we encounter errors in your testing, we can cancel the validation mode.
- To replace edition 1.0 with edition 2.0:
- Stop the validation target, for example, dynamic_cluster_1-Validation.
- Delete the routing rules specific to edition 2.0 to route all requests for the application to a single edition.
- Save changes and synchronize the nodes.
- Perform rollout to the new edition
-
Applications > Edition control center > application_name > edition 2.0 > Rollout
During the rollout, edition 2.0 is retargeted to its original deployment target, for example, dynamic_cluster_1. The edition state transitions from validation to active.
- If edition 2.0 has errors, we can cancel validation mode and move edition 2.0 back to its original inactive state. As a result, the duplicate dynamic cluster created for validation is removed. For more information about cancelling the validation mode, read about canceling an application validation.
Subtopics
- Cancel an application validation
We can cancel validation of an edition and return the application edition to inactive state.
Related: