The biggest danger in "rolling back" code changes in Remedy isn't in adding new functionality but in deleting old...particularly when fields/forms that are deemed "no longer needed" are deleted. When this happens, the data in the underlying database is deleted, too. If this happens, recovering that lost data can be very difficult--and in cases where proper backups aren't being accomplished, impossible.
In instances where forms/fields are NOT being deleted by an upgrade, what you can do is break out all existing workflow to a def file BEFORE the new defs are dropped in. Then drop in the new defs. If somewhere down the road you hit that awful point where you're saying, "We shouldn't have done this...we introduced more bugs than we fixed," you can just delete all workflow and then just reload the old workflow from the def you created before applying the new. Norm -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Howard Richter Sent: Wednesday, August 22, 2007 10:07 AM To: [email protected] Subject: Re: Production ** Kathy, Our process is a little different and will reduce issues like you saw. BMC is not alone in not documentating all changes they make to code, so you should test and develop in a system as close to production as you can. So after we apply any patches to our production system and everything works for a few days, we refresh our development system with a copy of production. The best method would be to have a three tier system. A development system, test system and then production system So you develop on one, test your changes on another and then have a confidence when you move to production. Howard Richter On 8/22/07, Kathy Morris <[EMAIL PROTECTED]> wrote: ** Hi All, Our technical support imported remedy package of bug fixes into QA, then Production. Well because our QA environment is different than Production, all this functionality broke when the code was in production even though it tested ok in QA. So the remedy bug fix was rolled back. However when the roll back took place - other workflow was broken and data was lost. Does anyone have a method that works to successfully back-out remedy code if necessary.. I did notice that when they were identifying the code -- not all of the code was identified in the documentation. They are not that particular about documenting the code. Our business has to be able to roll back if something is goes wrong. ________________________________ Get a sneak peek of the all-new AOL.com <http://discover.aol.com/memed/aolcom30tour/?ncid=AOLAOF00020000000982> . __20060125_______________________This posting was submitted with HTML in it___ -- Howard Richter Remedy ServiceDesk Manager CedarCrestone Managed Services Center [EMAIL PROTECTED] __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
