Ok, então cheguei até aqui - não estou publicando isso como uma edição da pergunta, com a possibilidade de que, embora pareça estar no caminho certo, possa haver uma maneira melhor do que estou trabalhando . Figura eu deixaria a democracia decidir!
Usando esse link, consegui descobrir o formato do arquivo XML que deve ser usado com a setParamFileopção para msdeploy. No passado, eu também havia descoberto o formato do XML declareParamFile usando a GUI incorporada no IIS depois de instalar a Web Deployment Tool.
Portanto, dado um site chamado 'SiteA', com duas entradas de ligação no arquivo applicationHost.config da seguinte maneira:
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
<binding protocol="https" bindingInformation="*:443:" />
</bindings>
(O que significa, especificamente - qualquer endereço IP na porta 80 e qualquer endereço IP na porta 443)
O certificado real usado não é armazenado no applicationHost.Config, mas na configuração do Http.sys (de acordo com este artigo ). Quando o msdeploy prepara um pacote para o site, ele incorpora essas informações - o que pode não ser uma bênção, como mencionei no final.
A primeira etapa é declarar um arquivo xml de parâmetros que usaremos para parametrizar um único pacote para os servidores ativos de destino:
<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>
Observe os valores do atributo 'match =' nas duas entradas de parâmetros internas. Isso garante que a ligação correta seja substituída. Este é um Regex (conforme descrito neste artigo técnico ) que seleciona os valores de ligação existentes que devem ser alterados com o valor do parâmetro que será passado em um momento.
Guardamos isso como declareparameters.xml.
Com isso, agora podemos gerar um pacote parametrizado, em nossa caixa de teste, a partir do qual podemos implantar, usando esta linha de comando (isso é para 'imagem' de todo um IIS no qual nosso SiteA está presente):
msdeploy -verb:sync
-source:WebServer,computerName=localhost
-dest:package="parameterised.zip"
-declareParamFile:declareparameters.xml
Se o site estiver em um servidor diferente, substitua 'localhost' pelo nome desse servidor. O serviço Web Deploy Agent deve estar em execução na máquina de destino para que isso funcione.
Agora, declaramos um arquivo xml de parâmetros que realmente fornecerá valores de parâmetros para uma implantação em um servidor ativo:
<parameters>
<setParameter name="SiteA-http" value="[fixedIPAddress]:80:"/>
<setParameter name="SiteA-https" value="[fixedIPAddress]:443:"/>
</parameters>
E guardamos isso como
[targetServerName]parameters.xml
(no meu caso, tenho dois servidores de destino, cada um obtém seus próprios parâmetros xml com um nome de arquivo diferente e IPs ligeiramente diferentes em cada um).
Por fim, podemos executar a implantação parametrizada no (s) servidor (es) de destino com esta linha de comando:
msdeploy -verb:sync
-source:package="parameterised.zip"
-dest:WebServer,computerName="[targetServerName]"
-setParamFile=[targetServerName]parameters.xml
Portanto, agora podemos alterar os IPs da ligação Http ou Https e, se os originais forem suficientemente diferentes, podemos parametrizar qualquer número de ligações individuais que possam ser necessárias para esse site.
Até o momento, existe uma desvantagem - portanto, qualquer resposta alternativa apreciada - a configuração do SSL é copiada da máquina de origem no pacote - o que significa que, para que a configuração do SSL no site ativo esteja correta na implantação, tanto a máquina de teste quanto os servidores ativos devem usar exatamente os mesmos certificados SSL.
O que seria ótimo é se a caixa de teste pudesse usar um certificado interno ou autoassinado para verificação de integridade e, em seguida, aplicar o certificado SSL real na implantação real - novamente, parametrizado a partir dos arquivos XML.