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

Question

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

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

Примечания

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

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

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

Answer 1

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

Для локальной сети (то есть внутренних производственных серверов) мы вручную инициировали задачи «Развернуть развертывание», которые останавливают IIS (сайты и приложения), копируют новый сайт и перезапускают материалы IIS.

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

Я не уверен, что 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> 

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

Answer 2

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