TAMU team: TAMU in-place upgrade, round #2 Round 1 during Q4 upgrade (in place migration) failed. The code was not tested. Jason figured out where and logged defects. Round 2 for licenses and agreements scripts work. But other modules don't. Jason will add tickets and John Melconian are getting back to the dev teams responsible for the upgrade scripts. The scripts don't leave the system in a good and stable state. Not recoverable. No log of what went wrong. No exception handling. What completed and what didn't is unknown. There is no way to roll back. It fails badly. Not acceptable. Rollback is a requirement One can clone and test before placing in production, but we still need a graceful exist. Not sure a full rollback is reasonable at this time during the project. Need to know what it's going to do, log what it has done, if it fails, where & why, need to re-run starting at that point. Right no, no visibility at all. We might be relying too much on OKAPI. So we have no insight. |