Hello All,
I’m interested in knowing what are some of your thoughts about installing service packs and fixes across multiple Integration Servers. Basically, can you have different services packs and fixes for each Integration Server or it’s best to keep them consistent. Thanks in advance.
If the IS instances are in any type of cluster, it is important to keep them all the same–same OS, same OS patches/fixes, same JVM, same IS service packs and fixes, same packages, same libraries, same config, etc.
From a environment management perspective, if the IS instances are independent of each other, it may be a good rule of thumb to keep them all on the same patch levels for administrative consistency. Exceptions would be managed on an as-needed basis (e.g. can’t apply fix XX to instance XYZ for some reason, or must stay on 6.1 for some reason). In other words, a principle that may be useful for your circumstance is keep them all the same unless there is a specific and reasonable reason not to.
Hi All,
Further to the original post, I wonder what people’s feelings are about
a) the frequency that hotfixes are released for core functionality, and
b) the balance between staying “up-to-date” while not being at the “bleeding-edge” (ie I’m concious that many hotfixes are closely followed by newer ones, to repair problems introduced by the original hotfix).
I personally struggle with both of these issues.
Most hotfixes are “non-critical” and hence in theory aren’t advised that everyone installs them, but many of the non-critical patches include fixes for core/basic funtionality, that I would have thought most people need.
Can anyone out there give me an idea of the best-practice you’ve adopted to manage the benefit/effort balance?
I’m sure at the end of the day, everyone needs to manage this on their own case-by-case basis - but if anyone’s come up with a “framework” that helps them with these decisions, I’d love to hear from you!
Thanks for your time as always, everyone.
Cheers!
Normally, I follow this rule of thumb: Apply fixes and updates only when you need them. Generally, I don’t apply fixes or service packs just because they exist.
When faced with a particular problem, I try to not apply a fix or service pack “just to see what happens.” Been burned too many times. Unless the fix explicitly states it addresses the specific problem encountered, I won’t apply it.
HTH.
I agree with Rob’s comments.
One other reason to apply a service pack is to simply administration once you have applied several fixes that are included in a service pack. For example if you are building out new environments using an offsite data center operations team that is unfamiliar with the manual steps required to apply a fix and you have several fixes, it is sometimes easier to apply a service pack that rolls up those fixes since SP installation can be scripted and made to be almost operations-proof.
That said, you still have to regression test to ensure that the SP does not introduce new issues. Or, better said, to find out which new issues are introduced by the SP (there will always be some in my experience).
Mark
Thanks Mark and Raemon.
Valuable feedback… It’s good to know that it’s not just me who has been burned by the heat of a ‘hot’ fix! 
Mark, you made the comment “Or, better said, to find out which new issues are introduced by the SP (there will always be some in my experience).”.
Do you mean “find out the hard way when something stops working”, or pro-actively going out and finding out about the risks so they can be mitigated prior to applying the fix?
It goes without saying that the latter option would be the ideal, but I’ve struggled to find information about potential problems up front (eg even with hot-fixes that have been around for a while or superseded, there’s no “Known Issues” section in the associated readme). It’s hard to find KB articles for a problem, if you don’t know what the problem will be!
Is this your experience also, or am I looking in the wrong places?
Thanks again for your valuable input. Much appreciated.
Cheers.
I mean find out through careful regression testing in a production-like environment.
The foundation of operational stability is based on rigorous attention to standard operating procedures, standardization of architecture components and minimization of changes.
Applying a service pack or fix introduces change and many times this changed software introduces new bugs. No software vendor documents bugs that they don’t know about.
You the savvy WM customer have to read the details of each fix in each service pack to determine whether there is a good reason to apply it. Sometimes the risk of introducing new defects is outweighed by the number of critical fixes (that your environment needs) included in an SP, other times it is not.
Mark