Автоматизация развертывания .Net с помощью Cruise Control .Net - PullRequest
Новая
       17

Автоматизация развертывания .Net с помощью Cruise Control .Net

7 голосов
/ 03 апреля 2009

У меня сейчас есть CC.Net для сборки, и это круто. Но теперь я хочу пройти весь путь и использовать его для развертывания. Я думал об установке CC.Net на стадии подготовки и после завершения сборки, и она автоматически загружается, запускает триггер forcebuild для подготовки и заставляет его использовать msbuild и необходимые расширения для gac, установки служб ect. чтобы завершить установку.

Я также видел msdeploy, который, похоже, имеет схожие цели. Что вы думаете о моем плане и как вы все делаете автоматизированное развертывание?

Примечания

  • SMB (File Shares) отключены в промежуточной сети, что исключает возможность psexec. Причина, по которой он отключен, заключается в том, что мы хотели, чтобы сеть была заблокирована, и когда я спросил об открытии, мне сказали, что нужно открыть слишком много портов. Какое-то отношение к аутентификации?

    • Возможно, этот аргумент порта является койкой. Я уже настраивал общие ресурсы Samba, но я никогда не работал с Active Directory, поэтому я отключился и прослушал.

  • Открыты только FTP, RDP и HTTP

Ответы [ 2 ]

6 голосов
/ 03 апреля 2009

Ричард, мы не хотели размещать CruiseControl рядом с промежуточными или производственными серверами.

Для локальной сети (т. Е. Внутренних производственных серверов) мы вручную запускали задачи Production Deploy CC, которые останавливают IIS (сайты и пулы приложений), копируют новый сайт и перезапускают компоненты IIS.

Для развертываний DMZ (т. Е. Для Интернета, соединения AD-auth невозможны) мы делаем столько сборок, сколько можем внутренне и архивируем результаты, включая скрипт NAnt, который выполняет «последние шаги». Существует внутренняя задача CC, которая делает все это и передает файлы ZIP на целевые серверы. Для завершения процесса требуется ручное вмешательство: удаленный вход в систему, разархивирование, а затем запуск NAnt для «полного» развертывания (остановка / копирование / запуск / что угодно).

Я не уверен насчет GAC, но IIS кажется управляемым с помощью файлов .VBS 

' Connect to the WMI WebAdministration namespace.
Set oWebAdmin = GetObject("winmgmts:\\devserver.local\root\WebAdministration") 
' Specify the application pool.
Set oAppPool = oWebAdmin.Get("ApplicationPool.Name='ProjectName'") 
' Stop the application pool.
oAppPool.Stop
' now website; get the application website
Set objWebSite = GetObject("IIS://localhost/W3SVC/7") ' id of web site
' get the app pool object for the websites app pool id
Set objAppPool = GetObject("IIS://localhost/W3SVC/AppPools/ProjectName")
'stop the site
objWebSite.Stop()
' stop the app pool
objAppPool.Stop()

Для услуг мы используем psexec.exe через NAnt 

  <property name="Remote.Executor" value="${ToolsDir}\PSTools\psexec.exe" overwrite="false" />
  <!-- installs a particular windows service remotely from the command line -->
  <target name="installWindowsServiceRemote">
    <echo message="${Service.Install.Action}ing ${Service.Name} on ${Deploy.TargetServer}..." />
    <exec program="${Remote.Executor}">
      <arg line="\\${Deploy.TargetServer} ${Deploy.TargetFolder}\${Service.Name} /${Service.Install.Action}" />
    </exec>
  </target>

В любом случае, возможно, есть десятки способов подойти к этому - у нас работает внутренняя автоматизированная / внешняя ручная пошаговая настройка.

1 голос
/ 03 апреля 2009

Я согласен с Крейгом, вам не нужен CC.NET на ваших сценических серверах. Мы делаем все, начиная от сервера сборки и заканчивая разработкой. и сцена. Используя MSBuild, у нас есть цели, настроенные для каждой из компиляций, и для отправки всех частей на оба сервера или комбинации серверов в зависимости от среды. Таким образом, каждый проект на CC.net на сервере сборки соответствует цели или траекториям в MSBuild плюс все непрерывные сборки.

...