Использование Robocopy для развертывания сайтов - PullRequest
4 голосов
/ 12 сентября 2010

Я хочу иметь возможность быстро развертывать обновления на довольно занятом сайте.Для небольших сайтов я бы просто отправлял новые файлы по FTP поверх старых.У этого, однако, есть несколько больших dll, которые регулярно обновляются, и в то время как они копируют, сайт фактически недоступен (плюс есть хлопоты по созданию их резервных копий на случай, если что-то пойдет не так.

Мой планиспользовать TortoiseHg для синхронизации с промежуточной копией на сервере по FTP (с использованием netdrive или чего-то подобного). Затем я могу проверить, все ли работает гладко, и как только это будет завершено, я хотел бы запустить файл .bat (или что-то еще), которыйсоздаст резервную копию живого сайта (желательно только файлы, которые собираются изменить, но это не критично), а затем скопирует вновь измененные файлы на работающий сайт.

Если возможно, я также хочули копия игнорировать определенные каталоги (например, пользовательские загрузки), чтобы не перезаписывать эти файлы на живом сайте?

Я слышал, RoboCopy - это путь, но я не уверен, куданачать. Нужно ли мне вызывать 2 команды (1 для первоначального резервного копирования и одна для копии)? Есть ли способ восстановить тон живой сайт в прежнем состоянии, если что-то пойдет не так?

Сайт находится в ASP.NET и будет скопирован на сервер Windows 2003.

РЕДАКТИРОВАТЬ: становится немного сложнее, когда элементы web.config изменились, и их необходимо объединить, чтобы настройки промежуточных серверов (настройки приложений, строки подключения и т. Д.) Не развертывались на работающем сайте.Как это обрабатывается?

Ответы [ 9 ]

4 голосов
/ 21 сентября 2010

Мы используем следующее:

  • сначала создайте сайт с помощью msbuild в cruisecontrol.net для сборки двоичных файлов
  • заархивируйте развернутые в данный момент файлы в папке с метками временичтобы избежать потери данных в случае возникновения проблемы

    C:\DevTools\Robocopy\robocopy.exe /R:1 /W:10 /mir "D:\WebSite\Files" "D:\Webarchive\ArchivedFiles\Documents.%date:~0,-8%.%date:~3,-5%.%date:~6%.%time:~0,-9%.%time:~3,-6%.%time:~6,-3%" /XF *.scc

  • остановка сайта

  • развертывание сайта путем копированиявсе, кроме файлов, которые мы заархивировали (/ XD - это каталог eXclude)

    C:\DevTools\Robocopy\robocopy.exe /R:1 /W:10 /mir "c:\dev\site" "D:\WebSite" /XF *.scc /XD "D:\WebSite\Files"

  • копирование и переименование (на этот раз xcopy) файла release.config с правильныминформация для d: \ Website \ web.config (фактически, это то, что мы делали раньше, теперь у нас есть механизм доморощенного преобразования для изменения частей файла web.config на лету).

  • перезагрузите веб-сайт
  • (необязательно) удалите архив, созданный на втором шаге

В вашем случае вам нужно будет добавить флаги / XD для любого каталога, который вы хотитеигнорировать, такие как загрузка пользователей.И если рабочий файл web.config не является сложным, я бы действительно рекомендовал просто скопировать файл release.config, который вы поддерживаете как часть проекта, рядом с web.config

3 голосов
/ 18 сентября 2010

Является ли Robocopy жестким требованием?Почему бы не использовать MSBuild?Все, что вы перечислили, можно безболезненно сделать в MSBuild.

<!-- Attempt to build new code -->
<MSBuild Projects="$(BuildRootPath)\ThePhotoProject.sln" Properties="Configuration=$(Environment);WebProjectOutputDir=$(OutputFolder);OutDir=$(WebProjectOutputDir)\" />

<!-- Get temp file references -->
<PropertyGroup>
  <TempConfigFile>$([System.IO.Path]::GetTempFileName())</TempConfigFile>
  <TempEnvironmentFile>$([System.IO.Path]::GetTempFileName())</TempEnvironmentFile>
</PropertyGroup>

<!-- Copy current web configs to temp files -->
<Copy SourceFiles="$(OutputFolder)\web.config" DestinationFiles="$(TempConfigFile)"></Copy>
<Copy SourceFiles="$(OutputFolder)\web.$(Environment).config" DestinationFiles="$(TempEnvironmentFile)"></Copy>
<ItemGroup>
  <DeleteConfigs Include="$(OutputFolder)\*.config" />
</ItemGroup>

<Delete Files="@(DeleteConfigs)" />

...

<!-- Copy app_offline file -->
<Copy SourceFiles="$(CCNetWorkingDirectory)\Builder\app_offline.htm"  DestinationFiles="$(DeployPath)\app_offline.htm"  Condition="Exists('$(CCNetWorkingDirectory)\Builder\app_offline.htm')"  />

<ItemGroup>
  <DeleteExisting Include="$(DeployPath)\**\*.*" Exclude="$(DeployPath)\app_offline.htm" />      
</ItemGroup>

<!-- Delete Existing files from site -->
<Delete Files="@(DeleteExisting)"  />
<ItemGroup>
  <DeployFiles Include="$(OutputFolder)\**\*.*" />
</ItemGroup>

<!-- Deploy new files to deployment folder. -->
<Copy SourceFiles="@(DeployFiles)"  DestinationFiles="@(DeployFiles->'$(DeployPath)\%(RecursiveDir)%(Filename)%(Extension)')"  />

<!-- Delete app_offline file -->
<Delete Files="$(DeployPath)\app_offline.htm" Condition="Exists('$(DeployPath)\app_offline.htm')"  />

2 голосов
/ 12 сентября 2010

На серверах на основе Nix я бы использовал RSYNC, и я понимаю, что в Windows вы можете использовать DeltaCopy , который является портом RSYNC и имеет открытые источники (никогда не использовал DeltaCopy, поэтому, пожалуйста, проверьте его внимательно) В любом случае, если он работаеткак RSYNC, тогда он работает быстро и обновляет только файлы, которые были изменены.

Вы можете использовать различные параметры конфигурации для удаления файлов на целевом объекте, которые были удалены из источника, и вы также можете использовать добавление в файл.это исключит файлы или каталоги, т.е. локальный конфиг, вы не хотите копировать.и т. д.

Вы должны быть в состоянии сложить все это в один сценарий, чтобы запускать его по мере необходимости, а это значит, что вы можете проверить и рассчитать время, чтобы вы знали, что происходит.

1 голос
/ 18 сентября 2010

Проверьте эти ссылки, чтобы увидеть, помогают ли они:

Вы обнаружите, что robocopy.exe /? чрезвычайно полезен. В частности, вам понадобится переключатель /XF для исключения файлов и /XD для исключения папок.

Вам потребуется написать скрипт (например, bat, powershell, cscript), чтобы позаботиться о проблемах web.config.

0 голосов
/ 24 августа 2012

MSBuild великолепен, за исключением одного незначительного (или крупного, в зависимости от вашей точки зрения) недостатка.Он перестраивает двоичные файлы каждый раз, когда вы запускаете сборку.Это означает, что для развертывания из TEST в PRODUCTION или STAGE to PRODUCTION (или как называется ваша пред-производственная среда), если вы используете MSBuild, вы не продвигаете существующие двоичные файлы из одной среды в другую, вы перестраиваете их,Это также означает, что вы с уверенностью полагаете, что НИЧЕГО не изменилось в репозитории исходного кода с момента создания MSBuild для вашей подготовительной среды.Даже малейшая вероятность изменения чего-либо, крупного или второстепенного, означает, что вы не будете продвигать полностью протестированный продукт в своей производственной среде.В местах, где я работаю, это неприемлемый риск.

Войдите в Robocopy.С Robocopy вы копируете (надеюсь) полностью протестированный продукт в свою производственную среду.Затем вам потребуется либо вручную изменить ваш web.config / app.config, чтобы отразить производственную среду, либо использовать для этого инструмент преобразования.Для этой цели я использовал «Инструмент преобразования конфигурации», доступный на SourceForge - он работает так же, как преобразования web / app.config MSBuild.

0 голосов
/ 22 сентября 2010

Возможно, вам понадобится комбинация инструментов.

Я бы посмотрел на DFSR (роль файлового сервера) с папкой только для чтения на вашем живом сайте (так что это односторонняя репликация).

Он очень прост в настройке, имеет приятный графический интерфейс, возможность исключать файлы на основе местоположения и / или масок, а с включенным Volume Shadow Copy вы можете запускать его по заданным вами графикам и обновлять только те файлы, которые изменяются ( или запустить его по расписанию, или даже запустить его вручную). Прелесть этого в том, что когда он настроен, вам больше не нужно его трогать.

После того, как вы скопируете большую часть своих файлов, вы можете получить помощь в автоматизации возможного слияния на web.config, если вы хотите, чтобы это было автоматизировано.

0 голосов
/ 22 сентября 2010

WebDeploy - намного лучший способ обработки развертываний (см. Скотт H http://www.hanselman.com/blog/WebDeploymentMadeAwesomeIfYoureUsingXCopyYoureDoingItWrong.aspx)

. Но Robocopy - это отличный недорогой инструмент развертывания, который я до сих пор использую на некоторых сайтах (не нашел времениизменить их на webdeploy). Robocopy похож на xcopy, но с гораздо более богатым набором параметров. Поэтому вам потребуется 2 команды Robocopy (1 для резервного копирования и 1 для развертывания). Обычно я делаю команду резервного копирования, когда файлы находятся в стадии подготовки.1004 *

Управление файлами конфигурации всегда сложно (и это серьезная причина для использования webdeploy). Один из подходов заключается в том, чтобы сохранить копию файлов конфигурации для каждой среды, проверенную в вашем контроле исходного кода (например, web.dev.config, web.uat.config, web.prod.config и т. д.) Этап (или сценарий развертывания) будет захватывать и переименовывать необходимый файл конфигурации.

0 голосов
/ 22 сентября 2010

Что вам нужно (и мне нужно) - это программа синхронизации с возможностью создания резервной копии файлов на сервере и быстрого копирования по FTP файлов по одному, возможно, сначала скопировав их во временный каталог, либо путем частичного обновления.

Это одна программа, которую я нашел: http://www.superflexible.com/ftp.htm

0 голосов
/ 18 сентября 2010

Microsoft сами используют robocopy для развертывания обновлений на некоторых сайтах.

Я не знаю, есть ли у вас несколько серверов, но наш сценарий развертывания работал примерно так: 1) Остановить IIS (который вывел бы сервер из ротации балансировщика нагрузки, 2) RoboCopy / MIR из \ STAGING \ path \ на \ webroot на \ WEB ## \ path \ to \ webroot, где ## - номер сервера, 3) Запустите IIS. Это было сделано после того, как сайт был протестирован на промежуточном сервере.

Это не сильно поможет с вашей конфигурационной проблемой, но наши промежуточные и производственные конфигурационные файлы были одинаковыми.

...