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] _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
