Automatyczne wdrażanie przy użyciu CI server

Używamy TeamCity do naszych wdrożeń oprócz CI i działa naprawdę dobrze. Oto kilka rzeczy, które mogą pomóc:

• Jeśli używasz VS2010, sprawdź SlowCheetah plugin . Może on wykonać transformację pliku konfiguracyjnego, aby zrobić to, czego potrzebujesz, aby zastąpić ciągi połączeń DB i inne zmienne wrażliwe na środowisko. Transformacje te następują automatycznie podczas budowania w oparciu o wybraną konfigurację budowania.
• Zobacz MSDeploy . While it gets większość uwagi zajmuje się wdrażaniem aplikacji internetowych, może robić wiele innych rzeczy, takich jak instalowanie usług systemu windows i synchronizacja plików z katalogiem docelowym. Podczas gdy większość ludzi instaluje go jako dodatek do usług IIS, można go zainstalować jako oddzielną usługę, która nie ma zależności od usług IIS.

Jeśli nie używasz VS2010 (lub nie chcesz używać SlowCheetah), oto jak poradzisz sobie z ustawieniami konfiguracyjnymi:

• Stwórz konfigurację aplikacji dla każdego innego środowiska (I ' m zakładając, że skonfigurować konfigurację kompilacji dla każdego środowiska). Dodaj nazwę konfiguracji na końcu pliku konfiguracyjnego, więc w Prod mamy App.config.Prod i QA mamy App.config.QA.
• Umieść pełną konfigurację dla każdego środowiska w odpowiednim pliku konfiguracyjnym dla to środowisko.

• Jako część kompilacji (używamy celu" BeforeBuild " w pliku projektu), użyj msbuild do skopiowania aplikacji specyficznej dla środowiska.config nad rzeczywistym. Oto zwyczaj msbuild target używamy do tego celu:

  <PropertyGroup>
      <EnvironmentAppConfig>App.config.$(Configuration)</EnvironmentAppConfig>
  </PropertyGroup>
  
  <Target Name="ReplaceAppConfig">
      <Message    Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')" 
                  Text="Copying $(EnvironmentAppConfig) -> App.config" Importance="high" />
  
      <Message    Condition="!Exists('$(ProjectDir)$(EnvironmentAppConfig)')"
                  Text="No $(EnvironmentAppConfig) found. Leaving App.config as is." Importance="high" />
  
      <Copy   SourceFiles="$(ProjectDir)$(EnvironmentAppConfig)"
              DestinationFiles="$(ProjectDir)App.config"
              Condition="Exists('$(ProjectDir)$(EnvironmentAppConfig)')" />
  
  </Target>
  

TeamCity + Octopus deploy

Octopus for Windows service automated deployes

Nasz zespół ds. wydania używa Anthill Pro - to również potrafi zrobić CI, ale po prostu używa go do wdrażania pakietów (w naszym przypadku głównie kodu strony www). Fajną rzeczą w Anthill jest cała konfiguracja klienta (agenta) - serwera, więc z pewnym wysiłkiem przemierza firewalle, NAT itp. I ma zatwierdzenie i planowanie przepływu pracy.

Jeśli chodzi o configs, to jest to inna bestia-niestety zarówno devs, jak i release team muszą je zmienić i jakoś scalić wynik. Zastanów się, czy chcesz Dodaj nowy klucz konfiguracji, ale zespół wydający musi dodać ustawienia produkcyjne dla połączenia DB. Sztuczka polega na tym, że deweloperzy nie powinni znać łańcucha połączenia dB produkcji. Tak więc nie jest to zautomatyzowane(w naszym przypadku tak czy inaczej).

Jestem częściowy do TeamCity, który jest produktem Jetbrains, firma, która sprawia, że podstawowe ReSharper(Nie, Nie pracuję dla nich, drat szczęście). TeamCity, przynajmniej jak ostatnio sprawdzałem, to darmowy produkt dla maksymalnie 20 użytkowników i 20 konfiguracji kompilacji. Ma kilka ładnych funkcji auto-build I blame. Wspaniale, naprawdę.

Wspominasz o komercyjnym narzędziu...

TFS, a konkretnie Team Build, w pełni wspiera budowanie kodu i jego wdrażanie. Za każdym razem, gdy tworzymy aplikację internetową, jest ona automatycznie wdrażana na naszych serwerach Dev i QA. Po wdrożeniu mamy go uruchomić przez pakiet testów internetowych, aby upewnić się, że wszystko jest funkcjonalne. Wtedy prawdziwa zabawa zaczyna się od naszego zespołu QA;)

Chociaż nie wdrażamy się automatycznie do produkcji, z pewnością możemy to zrobić również.