Activate concurrent application editions
Activate multiple editions of the same application concurrently...
- when we are validating before production
- piloting an application to a select group of users
- rolling out a branch when an application upgrade requires a corresponding change on identifiable branches of client machines
We must have at least two editions of the same application installed. For example, the my_application application edition 1.0 is installed on the dynamic_cluster_1, and application edition 2.0 is installed on the dynamic_cluster_2.
Privileges for the application edition manager differ, depending on the various roles. Roles include monitor, operator, configurator, and administrator. If we are a user with either a monitor or an operator role, we can only view the application edition manager information. If we have the role of configurator or administrator, we have all the configuration privileges for the application edition manager.
Each application edition must be active on a separate deployment target. When multiple editions of the same application are concurrently available to users in the same environment, the on demand router (ODR) cannot differentiate between the active editions without some information available to process the request and route it to the intended edition. Use routing rules or unique interfaces for each application edition to prevent ambiguity.
Restriction: Only one active edition of a PHP Hypertext Preprocessor (PHP) application is supported on a node. If we have active editions of the same PHP application, do not deploy the application to servers that are on the same node.
Tasks
- Activate the application editions
Applications > Edition control center > application_name > inactive edition > Activate
For example, select the my_application application and activate application edition 2.0.
- Create routing policies for each application edition.
- Verify that the ODR is running.
Servers > On demand routers
To route requests, the status must be Started.
- Test the concurrent access to application editions. Select the two application editions by selecting the servers associated with the two dynamic clusters, and click Start.
Edition 1.0 is serviced by the routing rule that we create for that particular edition, and edition 2.0 is serviced by its specific routing rule.
Example
To run a preproduction test of an application edition in the production environment with a selected set of users, we can clone the deployment target, including its resource and security definitions, and activate the target edition on the cloned environment. Use routing rules to direct the ODR to divert a selected subset of users to the application edition.
To pilot the application, we can use routing rules to separate the pilot users on edition 2.0 from the general users on edition 1.0.
In the case of branch rollout, use routing rules to direct each branch to the appropriate edition. As the client code at each successive branch updates, the server-side routing rules can be updated to qualify the clients from the newly updated branch to be sent to the appropriate edition.
For cases where the routing rules are insufficient to differentiate user requests or where the user prefers an alternative to routing rules, each edition can be given its own unique URI and EJB JNDI name. Unlike routing rules, unique interfaces for each edition are exposed to the application users. Therefore, we must choose the appropriate name to drive the appropriate edition.
What to do next
Perform validation to test the availability and resiliency of our new edition under realistic conditions.
Related:
Application edition manager concepts Install an application edition Perform a rollout on an edition Perform a rollback on an edition Validate an edition Create routing policies for application editions Intelligent Management: routing and service policies Intelligent Management: administrative roles and privileges