David, In general, I have always considered making changes in production to be either a scheduled situation, or an emergency thing. Any change going to production needs to first be developed in Dev, moved to Test via standard procedures, tested in test to ensure the functionality is working properly....then moved to Prod in the same manner it was moved to Test....so this essentially means that you are never using Dev Studio in Test/Prod with exception of importing already developed stuff. Adding users is standard operating procedures....but adding groups should not be as that causes re-caching of stuff on the server as well...it's almost analogous to doing code changes (but not 100% the same).
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of David Durling Sent: Monday, March 26, 2012 2:58 PM To: [email protected] Subject: Production changes (spin-off of RE: Effects of flushing midtier cache) Joe brought up an issue I already had questions relating to, being: what workflow IS okay to change on a production AR server during production hours? For instance, if I have an app on a production box that is being tested by users and is not itself "production", am I endangering other things on production by making changes to it during production hours? (Besides flushing the mid tier cache, that is.) Or do people have categories of changes - like rewording text in an email filter or on a form, or adding an item to a character menu - that they consider have an acceptable level of risk to do during normal hours? Or is it standard to just not touch anything with Developer Studio unless it's an emergency or a change window? Related question: Are updating groups or using the Data Import tool (on a reasonable, limited basis) considered normal production procedures? Thanks for any insights on this, David David Durling University of Georgia > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Joe Martin D'Souza > Sent: Monday, March 26, 2012 4:19 PM > To: [email protected] > Subject: Re: Effects of flushing midtier cache > > When would you need to flush cache? The obvious answer is when there is a > workflow change on production.. Changes to workflow are done whenever > there is need for code change for enhancement or bug fixes.. The general > industry practice is to manage these changes in a change window, where > there is a scheduled outage, which is typically scheduled on weekends or the > least productive hours of an organization. So cache should be flushed during > these changes. > > That being said, there may be emergency changes that were a result of a part > or whole system being rendered unusable pending that change. On such an > event it would be ok to flush your cache after fixing whatever the > problem/bug/enhancement was. > > Yes flushing cache during production hours may cause a brief negative impact > on users using the system at the time of the change. > > Joe > > -----Original Message----- > From: David Durling > Sent: Monday, March 26, 2012 3:48 PM Newsgroups: > public.remedy.arsystem.general > To: [email protected] > Subject: Effects of flushing midtier cache > > Hi, > > I'm one of those that has found it necessary to use the "flush cache" button > in the mid tier config when sometimes certain changes aren't picked up at > the regular cache check interval. > > Do you all consider a flush of the mid tier cache to be unintrusive - something > that can be done during production hours? Or is it something that should be > done off-hours? > > On our server I don't notice performance issues in using it, and in what little > testing I've done, user sessions seem to be uninterrupted. (I'm not sure > about floating users on the web, though - if there's anything to consider > there.) > > I'm on ARS 7.5 patch 007 with mid tier 7.5 patch 007 with apache/tomcat. > > Thanks, > > David > --- David Durling [email protected] Enterprise IT Services 706-542-0223 University of Georgia ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
