Ok, então cheguei até aqui - não estou postando isso como uma edição da pergunta, na chance de que, embora isso pareça estar no caminho certo, pode haver uma maneira melhor do que está trabalhando. Figura eu deixaria a democracia decidir!
Usando setParamFile do msdeploy. . Eu também, no passado, descobri o formato para o XML declareParamFile usando a GUI incorporada no IIS depois de instalar a Ferramenta de Implantação da Web.
Assim, dado um site chamado 'SiteA', com duas entradas de ligação no arquivo applicationHost.config da seguinte forma:
<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 que está sendo 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 eu mencionei no final.
O primeiro passo é 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 do parâmetro interno. Isso garante que a ligação correta seja substituída. Este é um Regex (como descrito em este artigo de technet ) que seleciona o valores de ligação existentes que devem ser alterados com o valor do parâmetro que será passado em um momento.
Nós salvamos isso como declareparameters.xml .
Com isso, agora podemos gerar um pacote parametrizado, a partir de nossa caixa de preparo, a partir do qual podemos implantar usando essa linha de comando (isso é 'image' um IIS inteiro 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 da Web diferente, substitua "localhost" pelo nome desse servidor da web. O serviço do 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, na verdade, fornecerá valores de parâmetro 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 nós salvamos isso como
[targetServerName]parameters.xml
(no meu caso eu tenho dois servidores de destino, então cada um recebe seus próprios parâmetros xml com um nome de arquivo diferente e IPs ligeiramente diferentes em cada um).
Finalmente, podemos executar a implantação parametrizada para o (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
Agora, podemos alterar os IPs do Http ou Https Binding e, se os originais forem suficientemente diferentes, podemos parametrizar qualquer número de ligações individuais que possam ser necessárias para esse site.
Isso tem uma desvantagem até agora - então qualquer resposta alternativa apreciada por favor - a configuração SSL é copiada da máquina de origem para o pacote - o que significa que para que a configuração SSL no site ao vivo esteja correta na implantação, A máquina temporária e os servidores ativos devem usar exatamente os mesmos certificados SSL.
O que seria ótimo se a caixa de teste pudesse usar um certificado autoassinado ou interno para verificação de integridade e, em seguida, ter o certificado SSL real aplicado na implantação real - novamente, parametrizado a partir dos arquivos XML.