Showing results for 
Show  only  | Search instead for 
Did you mean: 

Collectors at a different minor version as a control mechanism for release upgrades?



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.




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)

Thanks for the suggestion David. We're already using that method for some of our environments but it's a bit tricky and very cumbersome (see also this post), more so because I have to ask the admins of the different environments to do it.

Here is an RFE that you could support by adding your case and vote up.

Synced bootstrapped Agent migration