Hi Janet,
I'm automating some emails into our backout process which inform the users that their elements are now out of synch and they need to get it fixed.
This feels like only a partial solution to the issue, because logically following this through I could just automate what I think the right thing to do is (ie re-apply the previous version to the final ENDEVOR environment). Hmm, is that ok with audit?
We've also been asked to implement element backout, this has been an ENDEVOR feature since V15.
So here's the thing, it works ok but it's really clunky - the panels can take an age to appear if you have large packages, it's really easy to miss the element and get the wrong one and even when you've done that work all it does is back out the element in the final ENDEVOR environment, you still (if on a remote machine) have to ship the old element. Endevor packaging and especially the backout piece with shipment appears overly complex and with customisations of having multiple targets and large /multiple packages, things aren't any simpler (eg like standard shipment the added scripting of database rebinds / phase in a CICS programs, recopy listings).
So I'd need to automate this into a pipeline like my existing backout process which allows our operations team to backout based on CCID and then (if shipped to multiple targets) choose the ones they want to remove the package from.
If I'm doing that then maybe I should think about just driving my own panel of elements, driven from a new menu eg:
OPTIONS:
- BACKOUT PACKAGE (BY CCID) - ALL ELEMENTS / ALL TARGETS
- BACKOUT SPECIFIC ELEMENT(S) (ALL TARGETS)
- BACKOUT SPECIFIC ELEMENT(S) (SPECIFIC TARGET)
In short I'd like CA to spend some time thinking about this whole thing maybe arrange some end-user sessions with admins to try and come up with a better solution.
As Stuart mentioned, it's been asked before. The idea has 16 votes up but 2 down (it's odd way that the tool CA uses works and has been configured) as to me if you don't want a feature don't vote on it, we could do with some clarity from CA what downvoting means to then. As it's been stationary for 4 years it could mean that it will never be investigated.
DevOps in theory leads to a fix forward mentality but it's never as simple as just one thing, there are also dependencies on the speed changes are implemented and the size and criticality to supporting areas which the associated risk.
Do you want your system on the floor whilst your support guys fiddle around trying to fix something (especially if it’s "just" going back to the previous version) or just press one button and back it out.
Backout is a great and required feature but it does need some TLC as it appears to have been neglected.
Steve Blackett (HSBC)