Właściwy sposób ustawiania ciągów połączeń w ci podczas msbuild/wdrożyć

Question

Mam serwer CI (Bamboo, ale nie sądzę, że to ma znaczenie) budowanie i automatyczne wdrażanie mojej aplikacji. Podczas rozwoju lokalnego używam localdb (<connectionStrings> węzeł w moim web.config)

<add name="MyApp" providerName="System.Data.SqlClient" connectionString="Data Source=(LocalDB)\v11.0;Integrated Security=True;Connect Timeout=30;Initial Catalog=MyApp" /> 
    <add name="MyApp_Patients" providerName="System.Data.SqlClient" connectionString="Data Source=(LocalDB)\v11.0;Integrated Security=True;Connect Timeout=30;Initial Catalog=AppleHms_MyApp" /> 
    ... 

Po wdrożeniu oczywiście nie należy używać. Powinien używać ciągu połączenia mojego serwera sql wdrażania.

Wiem, że mogę napisać transformację web.config i wiem nawet, że mogę zaszyfrować plik web.config, ale nie jestem pewien, jak powinien wyglądać ciąg połączenia db. Jaki sens jest dla mnie na serwerze CI nadpisywać connectionString - więc mój config przekształcić powinien może wyglądać następująco

<?xml version="1.0" encoding="utf-8"?> 
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"> 
    <connectionStrings> 
    <add name="MyApp" providerName="System.Data.SqlClient" connectionString="${main-db-connectionstring}" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" /> 
    <add name="MyApp_Patients" providerName="System.Data.SqlClient" connectionString="${patients-db-connectionstring}" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" /> 
    ... 
    </connectionStrings> 
    <system.web> 
    <compilation xdt:Transform="RemoveAttributes(debug)" /> 
    </system.web> 
</configuration> 

z nadpisania pochodzących od zmiennych w moim serwerze CI (przypuszczalnie jakąś część msbuild lub wdrożyć)?

Czy to prawda, że ​​jest to "właściwy" sposób na zrobienie tego? Co dokładnie mam zrobić z msbuild/deploy, aby to się stało?

Answer 1

Korzystanie zadanie XMLPoke byłby właściwy sposób, aby to zrobić za pomocą skryptu MSBuild

XMLPoke on MSDN

również uzyskać bardzo dobre referencje, sprawdzić Sayed Ibrahim Hashimi blog, zawsze pomocny

Answer 2

Jesteśmy również za pomocą bambusa dla CI i wdrażania, a co robimy to:

• Projekt pakietów zawierający domyślny parametr Parameters.xml jako t on plik deklaracji parametrów msdeploy.
• Utrzymywanie plików SetParameters.xml dla różnych warunków środowiska.
• Projekty opakowań na wieczorną kompilację.
• Uwalnianie nocnych paczek jako artefakty z bambusa.
• Użycie msdeploy do zastosowania parametryzacji w tych pakietach podczas wdrażania dla określonej kompilacji nocnej.

Zasadniczo rozmieszczenie jak to dotyczyć msdeploy jest jak w następujący sposób:

msdeploy 
    -verb:sync 
    -source:package="NightlyPackage.zip" 
    -dest:iisApp="YourIISHost/YourIISSite" 
    -declareParamFile="YourEnvironementSetParameters.xml" 

Twój Parameters.xml za pakiet projektu będzie wyglądać następująco:

<parameters> 
    <parameter 
     name="ConnectionString1-Web.config Connection String" 
     description="" 
     defaultValue="localhost"> 
      <parameterEntry 
      kind="XmlFile" 
      scope="\\web.config$" 
      match="/configuration/connectionStrings/add[@name='ConnectionString1']/@connectionString" 
      /> 
    </parameter> 
</parameters> 

Gdzie ConnectionString1 to nazwa połączenia connectionString.

A twój YourEnvironementSetParameters.xml będzie wyglądać następująco:

<parameters> 
    <setParameter name="ConnectionString1-Web.config Connection String" value="Your parametrized connection string value " /> 
</parameters> 

Istnieją konwencje przy użyciu parametryzacji w niektórych dziedzinach z webdeploy. Są traktowane ciągi połączeń, więc dobrze jest przestrzegać poniższego nazewnictwa parametrów, jeśli chodzi o odwoływanie się do sieci.ciąg połączenia konfiguracji:

%NameOfYourConnectionStringAsInWebConfig%-Web.config Connection String