Managing (deleting) abandoned development work in production environment

[jMarshal]

Hello everyone - after many years of use, we seem to have a lot of old, retrieved update sets which are uncommitted in our production environment. This is all abandoned development, none of it is going to be committed in production.

This causes confusion and frustration with our developers and implementers...and I'd like to just "take out the trash" and mass delete all previewed and loaded (uncommitted) update sets on our "retrieved update sets" table (sys_remote_update_set).

...is this a safe practice? Is there any other archival/clean-up technique that would be better suited for this?

I'm thinking this is safe, because these are all uncommitted and the only risk would be in managing current development which is not yet deployed, but is still in progress, working towards deployment. I am mitigating that risk manually by setting a deployment freeze window.

Any input is appreciated!

[Sandeep Rajput · Accepted solution]

@jMarshal Although, the deletion would take place on uncommitted update set, still I would recommend you to make a clone of your production instance on a sub prod instance instance and perform the deletion on the sub prod instance. Once everything verified, you can proceed to make the deletion of those update set on production.

You can use Delete Jobs to schedule the delete operation in non business hours.

[Sandeep Rajput · Accepted solution]

@jMarshal Although, the deletion would take place on uncommitted update set, still I would recommend you to make a clone of your production instance on a sub prod instance instance and perform the deletion on the sub prod instance. Once everything verified, you can proceed to make the deletion of those update set on production.

You can use Delete Jobs to schedule the delete operation in non business hours.

[Mark Roethof · Accepted solution]

Hi there,

Unmanaged this case indeed grow extremely large and make it a lot more difficult when deploying or even accidently opening the wrong retrieved update set.

What I usually do at customers is implement scheduled Instance Scan Checks, one of them checking for uncommitted update sets in production. This way the customer is noticed immediately and can take action. For example by deleting the retrieved update set (which is fine to do!) + changing the state of the local update set on the source instance to ignore so it won't be retrieved again.

[jMarshal]

Thank you both @Mark Roethof and @Sandeep Rajput for the immensely helpful advice!

This answers my immediate questions (is it a safe practice?) and sets me up for future success by providing some additional advice that will help me manage and act on this better, in the future! Thanks again! 😁