Ad-hoc Artifact deployment in IBM MobileFirst Platform Foundation Server - ibm-mobilefirst

Question

1) What is the approach to take when there is a need to deploy the
artifacts on the fly during normal production
2) Are there any specific artifacts that might need any careful
consideration when deploying during normal production
3) What can be expected to change in system behavior when a on-the-fly
artifact deployment occurs such as sync, transaction failures, memory
usage increase etc and possibly list them out as much as we can so we
can watch out for it
4) As part of 3 above, what is the proper action to take under such
failures such as
4.A) What to do when for some reason sync failures occurs - server restart
etc?
4.B) What to do when a transaction fails as a result of new artifact
deployment - suggest any client code changes that inlcudes minitor for
failure callback and inform the user with a meaningful message or
automatic retry?

Answer 1

1) What is the approach to take when there is a need to deploy the
artifacts on the fly during normal production
Whenever a new artifact needs to be deployed, the environment takes a small downtime and traffic to the environment is blocked. The artifacts are updated.
Restart the servers if required. Open the traffic for the application.
The downtime is usually taken at non peak hours for the application.
2) Are there any specific artifacts that might need any careful
consideration when deploying during normal production
The only artifacts that are updated are the Runtime WAR file,
adapters and wlapps.
The WAR file is usually updated if there is an iFix upgrade. (Requires a
downtime).
The wlapp can be of 2 types.
The wlapp is for a new version. (Requires no downtime as there is no
traffic as yet for a new version).
The wlapp upgrades the existing hybrid application. (Advice a
downtime as direct update will be immediately triggered on all devices
connecting).
The adapters are updated to fix functionality. (Advice a downtime as
sensitive transaction flows are interupted).
The adapters are new. (Requires no downtime).
3) What can be expected to change in system behavior when a on-the-fly
artifact deployment occurs such as sync, transaction failures, memory
usage increase etc and possibly list them out as much as we can so we
can watch out for it
This is completely application logic dependant. The sync failures
could occur when the WAR file is updated. But when WAR file is updated
, a restart of the Application server is advised anyways. Transaction failures are application logic
dependant so they are undefined. Memory usage also depends on how the
application logic has changed. Unless the changes are major, they should
work fine.
4) As part of 3 above, what is the proper action to take under such
failures such as
4.A) What to do when for some reason sync failures occurs - server restart
etc?
Need to check with WebSphere support team as to why the sync failed. The
server restart should be sufficient to resolve any sync issues. But if
the sync failures across cluster are a common thing please collect logs
and open a PMR to be review by WAS support
4.B) What to do when a transaction fails as a result of new artifact
deployment - suggest any client code changes that inlcudes minitor for
failure callback and inform the user with a meaningful message or
automatic retry?
The application logic should handle the transaction failure. The adapter code
should gracefully send a meaningful message and request user to try
again.