The JADE 2022 release meets tomorrow’s business demands.
A combination of business demands and a transition to more agile software delivery techniques sees us needing to deploy code to the next jade environment in the chain through to production at ever more frequent rates. Previously for Test bases this occurred overnight, now it is expected multiple times per day.
We have multiple Developers and Testers working on different changes in their respective shared environments, so dropping these to allow for changes to be successfully made is disruptive and largely impractical, let alone hotfixes to production environments.
Examples of deployment issues include class locks where structural changes are made to transients, changes to forms if that form has been previously opened, and I guess the biggie is reorg completion.
The ultimate achievement would be where any changes could be deployed to an environment while it is running without any impact or downtime to the users or functionality, effectively enabling a full continuous delivery capability. Appreciating that this is a wide ranging and difficult problem to crack, so perhaps the community could identify the most common cases and we work through those?
John Beaufoy
This is achievable but the product owners need to be willing to take it there. As well as being a fantastic capability for our systems and customers, it would be a great addition as a selling point for the product.
Removing the need for any downtime altogether is likely to be a challenge - but at least getting us to a point where we can apply all our changes to the latest schema version, for which the re-org can be carried out while still online, minimising the downtime to the final transition phase would be ideal. We can't do this currently because there's various scenarios where we have to complete an intermediary re-org/transition before applying subsequent changes during a deployment. PAR's highlighting scenarios where we can't apply a change because prior changes in latest schema version aren't adhered to by validation include 66557 & 67022, 67023. The need to address issues of this nature for the benefit of schema evolution has also been discussed by JEDI #457 (complete JCF support) & #102 (better support for deploying map file related changes).
I could potentially see form changes that are open/previously opened, if there was someway to close a particular form across all clients, for example someone leaves the application open at the end of the day and you want to make a form change, but when that happens we just force them off via monitor. I don't know how you would ever get a reorg to happen while the system is in use as anyone could use that class at any time. Something I was thinking was renaming attributes/references, when you right click and hit change it will say the class is in use but I'm thinking just a rename would be fine and it wouldn't matter if the class is in use?