How to upgrade to IdP 4.0.0 'in place' when install is configuration managed

[Cantor, Scott]

On 4/22/20, 7:35 PM, "users on behalf of Marc Jay" <users-bounces at shibboleth.net on behalf of marc.jay at taskize.com> wrote:

> My question then being - are we really better off creating a dev environment, upgrading in place and then pulling those
> files back off the server and then into source control and configuration management?

Yes.

> It feels like as long as we don't mind repeating some of our customisation, we could start with a fresh install, but if
> there's some reason why that's such a bad idea I would appreciate understanding why or what in particular we should
> look out for with that approach?

If by "repeating customizations" you mean literally copying back in all of the non-system files that are present in both versions, for the most part the end result is going to be the same because that's what the upgrade process does. Since that basically just does the work the installer would do for you, I don't really see the benefit of it either. One missed file and you don't know the result.

I don't believe this release adds new properties to maintain function. But I don't know, and if it does, I wouldn't apologize for saying it doesn't, because that's just not how this works. We designed and tested the actual upgrade process, not other ways to do it.

The reason the advice is so strongly worded is that copying *all* the files like that is NOT what most people do when they try this. They start picking and choosing what to copy in each file by hand, leaving the files in a mixed state that don't function properly because they don't know what they really changed and they don't know what was added that changes behavior for *new* systems but not upgraded ones.

If all the files are copied back en masse, that is generally the same state the installer leaves it in. Generally. Probably for this release. Not necessarily all releases.

-- Scott