Hmm.... at a previous job, we used config files (the xml ones) to at least deal with connections - one file per resource (e.g., server+database).
The convention we used was that the SSIS servers or where they were run from had a local drive folder where their config files were stored. As developers and testers, we also had the same "local" drive (either via net use or subst), but our dev or test config files were in there - something like "C:\SSIS_Configs\". the config files were named the same throughout.
the ops people could keep their production passwords safe, with no one embedding passwords in SSIS packages, etc, and us devs and QA testers just had to copy the SSIS packages into our respective environments, whether it was our desktops or dev or testing servers. It all Just Worked, especially as it was one less thing to remember to check or fix when deploying packages up the chain to production.
For my SSIS packages, I prefer to use expressions and package variables where I can to "dynamically" twiddle these kinds of things. At the very least, while the command-line (DTEXEC) syntax for setting values to package variables is painful, it also just works... It could be that those package-level variables may need to be dynamically set at the command line as well. For example, our ops system could return certain date range values (like 1st of month, 7th business day of month, etc). Those values could be picked out in the specific job and then passed into the packages easily enough, meaning these were defined and maintained in one place.