Ok so I got this far - I'm not posting this as an edit to the question, on the off-chance that although this appears to be on the right track, there might be a better way than what I've been working on. Figure I'd let democracy decide!
Using this link I was able to figure out the format of the XML file that should be used with the setParamFile switch for msdeploy. I'd also, in the past, figured out the format for the declareParamFile XML by using the embedded GUI within IIS after installing the Web Deployment Tool.
So, given a site called 'SiteA', with two binding entries in the applicationHost.config file as follows:
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
<binding protocol="https" bindingInformation="*:443:" />
</bindings>
(Which means, specifically - any IP address on port 80 and any IP address on port 443)
The actual cert being used is not stored in applicationHost.Config, but instead in the configuration for Http.sys (according to this article). When msdeploy prepares a package for the site, it will embed that information - which might not be a blessing as I mention at the end.
The first step is to declare a parameters xml file that we will use to parameterise a single package for the target live servers:
<parameters>
<!-- declare parameter for Http Binding -->
<parameter name="SiteA-http" description="SiteA Http Binding">
<parameterEntry kind="DestinationBinding" scope="SiteA" match=":80:" />
</parameter>
<!-- declare parameter for Https Binding -->
<parameter name="SiteA-https" description="SiteA Https Binding">
<parameterEntry kind="DestinationBinding" scope="SiteA" match=":443:" />
</parameter>
</parameters>
Note the 'match=' attribute values on the two inner parameter entries. This ensures that the correct binding is replaced. This is a Regex (as described in this technet article) that selects the existing binding values that are to be changed with the parameter value that will be passed in a moment.
We save this as declareparameters.xml.
With this in place, we can now generate a parameterised package, from our staging box, from which we can then deploy, using this command line (this is to 'image' a whole IIS within which our SiteA is present):
msdeploy -verb:sync
-source:WebServer,computerName=localhost
-dest:package="parameterised.zip"
-declareParamFile:declareparameters.xml
If the web site is on a different web server, replace 'localhost' with that web server's name. The Web Deploy Agent service has to be running on the target machine for this to work.
Now, we declare a parameters xml file that will actually provide parameter values for a deployment to a live server:
<parameters>
<setParameter name="SiteA-http" value="[fixedIPAddress]:80:"/>
<setParameter name="SiteA-https" value="[fixedIPAddress]:443:"/>
</parameters>
And we save that as
[targetServerName]parameters.xml
(in my case I have two target servers, so each gets its own parameters xml with a different file name, and slightly different IPs in each).
Finally, we can perform the parameterised deployment to the target server(s) with this command line:
msdeploy -verb:sync
-source:package="parameterised.zip"
-dest:WebServer,computerName="[targetServerName]"
-setParamFile=[targetServerName]parameters.xml
So now we can change the IPs of either the Http or Https Binding and, if the originals are sufficiently different, we can parameterise any number of individual bindings that might be required for that site.
This has one drawback so far - so any alternative answers appreciated please - the SSL configuration is copied from the source machine into the package - meaning that in order for the SSL config on the live site to be correct on deployment, both the staging machine and the live server(s) must use exactly the same SSL certs.
What would be great is if the staging box could use a self-signed or internal cert for sanity checking, and then have the real SSL cert be applied on the actual deployment - again, parameterised from the XML files.
Best Answer
Generally speaking your testing environment should be entirely separate from your production environment -- This allows you to test things like software updates before rolling them out to production, so if they break stuff you can determine what and how to fix it without the time pressures associated with your live environment being down.
My suggestion for an ideal scenario would be to build a development environment that is an exact copy of your production environment - same releases of all software, same database contents, etc. This can be made publicly accessible, or locked away behind a firewall where all your developers & QA folks VPN in to do their work (which way you go depends heavily on your workflow and processes, but I personally like the VPN solution).
It's also often advantageous to build your development environment using something like VMWare, where you can snapshot the environment before making major changes.
You will also need a process in place for promoting your changes to production. If you have the time to invest in a solution like Puppet or radmind now it will make future deployments much easier (VMWare comes in handy here too -- You can test your deployment process on virtual machines and debug it so when it runs in production you know how it will behave).