Excellent post Carey! Yes, minor fixes like that require on the fly changing which isn't a hard thing to get past management in our company (thank god). Most of our monthly enhancements are non-data impacting or the data that is added is not that critical. So we can afford to delete a field or two. However, there will come a time when our major releases (mostly critical data additions) need to be rolled back.
For the Major releases, we take more time in determining what the users requirements of those forms are so that we can get it right the first time and not have to rollback. The last time we did a enhancement release, something in production didn't like our changes, but we backed the database and forms/workflow like crazy before we did anything to the server (it was our first time doing a release). In fact, we did have to do a *roll back* in order to fix the problem and let our users continue working with Remedy so that we could look at the problem. We ended up releasing the small changes gradually over that month, making sure they worked correctly. Not really something we want to do again since we have a enhancement release every month. There will always be bugs that you cannot find on test that will happen in production, that is a fact. Just hope to minimize those. I will definantly use those steps when I do the release in a couple of weeks and make sure I do them on test first before pushing em over to production. Bob Halstead -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Monday, September 25, 2006 11:46 AM To: [email protected] Subject: Re: Best ways to rollout new features. Robert, Now hold on a second... You want a "roll back" feature too? That might be asking a bit much for the simple Packing List. :) Let me be clear by what I mean by that... Let's say a simple change is to add a new required field to a single form. You deploy the change. All is well in production for some short time period. Let's say 1/2 a business day. Now your management comes to you add says something like... " Yes, we told you to make it a required field, but we were wrong. It needs to be optional. But back out the full change and we will redesign it and put the field back later." ( Because they think it is a major issue to make a field optional instead of required.) Then they add... "Oh, but we want to keep all of the data that the users have already entered on the system too." Now you have a pickle. What you need to do is NOT roll back the change, but make an on the fly change to "correct a minor bug". :) Some change control processes will not like that answer, but that is what management would be asking for. On a more complicated release the "roll back" could mean deleting new workflow (Active Links/Filters/Escalations/Menus) that were added and "regressing" existing workflow that was altered in the deployment too. Most workflow things are fairly easy to sort out, but the data is where it gets real messy. Packing lists can provide a part of a "roll back" process, but not a full solution. You may need to do something like this three step process... 1) Export the Packing List and all contained objects from DEV. (AKA: "release Packing List") 2) Import ONLY the Packing List object to PROD/TEST. Export the packing list (and all contents) from PROD/TEST. (AKA: "backup Packing List") Do the full deployment: Import the packing list and ALL contents to PROD/TEST. This will leave you with a "original set" of workflow/forms that were on PROD and were in the Packing List.(AKA: "backup Packing List") But what it will not tell you is the "New" objects that were added. That list can be found however from a diff of the "backup Packing List" and the "release Packing List". Those objects would need to be removed to do a full "roll back" too. Again... I will point you to the docs to gain a full understanding of the "import in place" options/details. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 9/25/06, Halstead, Robert <[EMAIL PROTECTED]> wrote: > ** > > I was definantly going to test the hell out of this before we push > this to production that's for sure lol. A lot of our forms (sadly to > say) are not in applications. So I'm thinking a packing list is more > of an option for me. Though, I think this will change the more I work > with remedy and need to *roll back* changes if/when something big goes wrong. > > > > Bob Halstead > ________________________________ > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of McKenzie, James J C-E LCMC > HQISEC/L3 > Sent: Monday, September 25, 2006 11:04 AM > > To: [email protected] > Subject: Re: Best ways to rollout new features. > > > ** > > Bob: > > Packing lists are the way to go if you are upgrading an existing > server. I would, however, backup my entire database instance before > doing an upgrade through this method. Again, I would also try this on > the test server before attempting to do this on the production system. > (I cannot emphasize this > enough.) > > James McKenzie > L-3 GSI > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Halstead, Robert > Sent: Monday, September 25, 2006 9:45 AM > To: [email protected] > Subject: Re: Best ways to rollout new features. > > We are using v6.03. I've looked at the packing list object but didn't > fully understand what it was used for. Class didn't cover it too much > (least not 2nd part Adminstrator class). Can anyone point me to a > link that explains this object? If I can get away with using a > packing list that would be awsome =) > > > Bob Halstead > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black > Sent: Monday, September 25, 2006 10:38 AM > To: [email protected] > Subject: Re: Best ways to rollout new features. > > Robert, > > I am not sure why you felt the need to "by exporting the form and > importing it on production one at a time". Maybe you had some "good reason" for that? > > Also ARS Server Version matters a bit here too. If you are post ... > v5? (definitely v6) then there is an import in place option during the > import to production that you should fully understand before you plan > how to do your release management too. > > I would also suggest that you look at the Packing List object. If you > can identify all objects that were changed on the dev server for a > given release then you can add them to a Packing List and use that > arbitrary list as a "package" of changes. > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > > On 9/25/06, Halstead, Robert <[EMAIL PROTECTED]> wrote: > > ** > > > > Sorry if someone has posted this before, I'm new to the list. I was > > wondering if there is a good way to rollout new features and > > enhancements to existing forms? We have a test box that we do all > > of our development work on and then push it to the production box. > > Since > > > we are new with remedy we've only done this once with some > > complications by exporting the form and importing it on production > > one > > > at a time. Is there was some type of way to rollout everything at > once in some sort of package? > > > > > > > > Bob Halstead > > > ______________________________________________________________________ > __ > _______ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > > ______________________________________________________________________ > _________ UNSUBSCRIBE or access ARSlist Archives at > http://www.wwrug.org __20060125_______________________This posting was > submitted with HTML in it___ __20060125_______________________This > posting was submitted with HTML in it___ ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
