As the administrator of just our dynaTrace APM solution and not of the environments themselves, I'm trying to find an manageable upgrade strategy for new dynaTrace
releases in our very heterogenous environments (preferably without getting shot by the admins of those environments).
For more than a year now, I had set my hopes on the development of a fixpack-like (now update-like, I guess) upgrade mechanism that would allow for controllable roll-out of new releases, so the possibility to determine which agents (environments) are allowed to upgrade at what time.
We really need a mechanism like that because upgrading our 5 different environments at the same time implies a synchronized maintenance window for those
environments in which all 'dynatraced' application processes can restart, which is near impossible to find (yes, I know, there's always the option to upgrade dynaTrace
and let the agents upgrade -and introduce new code in production- as a side-effect of a random process restart, but for that case, I'd like to refer again to the
environment admins shooting me).
Recently I read in the 6.2 dt online documentation that it's possible to connect collectors with the same major release number but with a lower minor release number to an upgraded dt server.
So I was wondering, would it be a bad idea to use this (within the same major release of course) as a mechanism to control what environments are upgraded at what time, provided we put each environment (agents) on their separate collector(s)?
Ideally it should not matter there's a month or more between the dt server upgrade and the upgrade of the last collector (environment) to the same minor version.
Does anybody already have experience with this?
Is there a reason why it's not recommended to try to work like that?
Thanks in advance for any feedback.
Solved! Go to Solution.
have you thought about using the libdtagentcore ? more and more of my clients are using that as a way to control when they update their agent binaries. It becomes a manual distribution at that point instead of using the bootstrap, but it allows them to follow controlled change management process(es)