Я помогаю поддерживать такую систему - в Дженкинс. Очевидно, что детали будут варьироваться в зависимости от структуры вашего проекта, но вот примерно то, что делает наша работа в Jenkins:
- Код извлечения (мы используем Git, но есть плагин Mercurial для Jenkins)
- Выполнить любые изменения схемы SQL для наших тестирующих БД из идемпотентного сценария (мы используем сценарий Ant, который предшествует нашему использованию Hudson / Jenkins)
- Запустите msbuild (еще один плагин Jenkins)
- Файл сборки - это наш .sln (или вы можете использовать web .csproj - аргументы немного отличаются)
- Аргументы командной строки:
- / p: Конфигурация = Dev / p: Платформа = "Любой ЦП" / p: DeployOnBuild = true / p: DeployTarget = Пакет /p:DeployIisAppPath="dev.mycompany.com/ "/ v: m
- При этом создается файл .zip, файл .cmd и некоторые файлы .xml, которые содержат все необходимое для развертывания обновлений на вашем сайте
- Запустите два других задания "msdeploy" Jenkins, по одному на каждом веб-сервере .NET
- Каждый веб-сервер .NET также является подчиненным Jenkins
- У нас на тестировании два сервера, балансировка по NLB
- Каждое задание «msdeploy» копирует файлы .zip / .cmd / .xml с сервера сборки во временную папку на веб-сервере, а затем запускает файл .cmd
- Файл .cmd выполняет msdeploy, который выталкивает все необходимое на ваш веб-сервер dev
У нас есть отдельная работа, которая запускает наши тесты NUnit, но вы также можете легко включить свои тесты в основную работу. Одна из причин, по которой мы собираем весь .sln вместо веб-.csproj, заключается в том, что мы можем запускать наши модульные тесты из того же встроенного кода.
Если вы еще этого не сделали, вам потребуется установить ASP.NET MVC3, .NET 4 и msdeploy на сервер сборки, и я полагаю, что вам также понадобится большинство таких же файлов на ваших веб-серверах.
Для планирования вы можете выбрать «периодически строить» или «опрашивать SCM» в качестве триггера сборки, а затем использовать cron-подобный синтаксис (0 0 * * *) для ежедневного запуска в полночь.