Mit Robocopy zu implementierende Websites

StackOverflow https://stackoverflow.com/questions/3694290

Frage

Ich möchte in der Lage sein, Änderungen zu einer Website schnell bereitstellen, die ziemlich voll ist. Für kleinere Standorte würde ich FTP nur die neuen Dateien über die alten. Dieser hat jedoch einige große DLL, die regelmäßig aktualisiert werden und während sie die Seite kopieren ist effektiv nach unten (plus gibt es die Mühe des Backups von ihnen, falls etwas schief geht zu machen.

Mein Plan ist TortoiseHg zu synchronisieren mit einer Staging-Kopie auf dem Server über FTP (mit NetDrive oder etwas ähnliches) zu verwenden. Ich kann dann überprüfen alles glatt läuft und einmal, dass eine vollständige ist, würde Ich mag eine .bat-Datei (oder etwas anderes) auszuführen, die eine Sicherung der Live-Website erstellen wird (vorzugsweise nur die Dateien, die etwa zu ändern sind, aber das ist nicht kritisch) und kopieren Sie dann die neu geänderten Dateien über die Live-Website.

Wenn möglich, möchte ich auch die Kopie haben ignorieren bestimmte Verzeichnisse (wie User-Uploads), so dass es nicht diese Dateien auf der Live-Site überschreiben?

Ich habe gehört, RoboCopy ist der Weg zu gehen, aber ich bin nicht sicher, wo ich anfangen soll. Würde ich brauche 2 Befehle aufrufen (1 für die erste Sicherung und eine für die Kopie)? Gibt es eine Möglichkeit, die Live-Site zu seinen vorherigen Zustand sollte etwas schief gehen wiederherzustellen?

Die Seite ist in ASP.NET und würde auf Windows 2003-Server kopiert werden.

EDIT: Es wird ein wenig schwierig, wenn web.config Artikel geändert haben und muß so zusammengeführt werden, dass die Staging-Server-Einstellungen (appsettings, Verbindungszeichenfolgen, usw.) nicht auf die Live-Website bereitgestellt bekommen. Wie funktioniert das get behandelt?

War es hilfreich?

Lösung

Was wir verwenden, ist die folgende

  • erste Build die Website mit msbuild in cruisecontrol.net die Binärdateien bauen

  • Archivierung der derzeit eingesetzten Dateien unter einem timestamped Ordner den Verlust von Daten im Falle eines Problems zu vermeiden

    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

  • Sie die Website beenden

  • auf der Website bereitstellen, indem Sie alles, was das Kopieren mit Ausnahme der Dateien, die wir archiviert (/ XD ist Ausschließen Directory)

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

  • Kopieren und Umbenennen (mit xcopy, diesmal) eine release.config mit korrekten Informationen zu d: \ Website \ web.config (in der Tat, das ist, was wir zu tun pflegten, jetzt haben wir einen Homebrew-Transformations-Engine zu ändern Teile des dev web.config on the fly).

  • starten Sie die Website
  • (optional) löschen Sie das Archiv, das Sie bei Schritt zwei

In Ihrem Fall, werden Sie den / XD-Flags für eine beliebiges Verzeichnis hinzuzufügen, müssen Sie ignorieren mögen, wie der Upload des Benutzers. Und es sei denn, die Produktion web.config kompliziert ist, würde ich wirklich nur empfehlen, ein release.config kopieren, die Sie als Teil des Projektes erhalten, Seite an Seite mit der web.config

Andere Tipps

Sie Robocopy eine harte Anforderung? Warum nicht MSBuild verwenden? Alles, was Sie schmerzlos aufgeführt haben, können in MSBuild erfolgen. 

<!-- 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')"  />

Auf Nichts basierten Server würde ich RSYNC verwenden, und ich verstehe, dass unter Windows können Sie verwenden Deltacopy , die eine Portierung von RSYNC und öffentlich zugänglichen Quellen (nie so verwendet Deltacopy sie sorgfältig prüfen) ist jedenfalls davon aus, es wie RSYNC dann funktioniert es schnell ist und aktualisiert nur Dateien, die geändert wurden.

Sie verschiedene Konfigurationsmöglichkeiten nutzen können Dateien auf dem Ziel zu löschen, die auf der Quelle gelöscht wurden, und Sie können auch einen Add in einer Datei verwenden, die Dateien oder Verzeichnisse, das heißt die lokale Konfiguration ausschließen, Sie wollen nicht kopieren. usw.

Sie sollten in der Lage sein, es zu falten alle in ein Skript bei Bedarf ausgeführt werden, was bedeutet, können Sie testen, und Zeit, so dass Sie wissen, was passiert ist.

Check out these links to see if they help:

You'll find that robocopy.exe /? is extremely helpful. In particular you'll want the /XF switch for excluding files, and /XD for excluding folders.

You will need to write a script (e.g. bat, powershell, cscript) to take care of the web.config issues though.

Microsoft themselves use robocopy to deploy updates to some sites.

I don't know if you have multiple servers, but our deployment script went something like: 1) Stop IIS (which would take the server out of load-balancer rotation, 2) RoboCopy /MIR from \STAGING\path\to\webroot to \WEB##\path\to\webroot where ## is the number of the server, 3) Start IIS. This was done after the site was smoke-tested on the staging server.

That doesn't much help with your config problem, but our staging and production config files were the same.

What you need (and I need) is a synchronize program with the ability to create backup of the files on the server, and make quick copy over ftp of the files at ones by probably copying them first on a temporary directory, or by partial updating.

This is one program that I found : http://www.superflexible.com/ftp.htm

WebDeploy is a much better way to handle deploys (see Scott H http://www.hanselman.com/blog/WebDeploymentMadeAwesomeIfYoureUsingXCopyYoureDoingItWrong.aspx)

But, Robocopy is a great low-cost deploy tool that I still use on some sites (haven't find the time to change them to webdeploy). Robocopy is like xcopy but with a much richer set of options. So you would need 2 Robocopy commands (1 for backup and 1 for deploy). I normally do the backup command when the files are staged.

Managing config files is always tricky (and a big reason to use webdeploy). One approach, is keep a copy of the config files for each environment checked into your source control (eg, web.dev.config, web.uat.config, web.prod.config, etc). The staging (or deploy script) would grab and rename the necessary config file.

You would probably need to use a combination of tools.

I would have a look at DFSR (File Server role) with a read-only folder on your live site (so it's one-way replication).

It is very easy to configure, has a nice GUI, ability to exclude files based on location and/or masks, and with Volume Shadow Copy enabled you can have it running on schedules you set and updating those files that change only (or have it run on a schedule, or even run it manually). The beauty of this is once it is configured, you don't have to touch it again.

Once you have the bulk of your files replicating you could then get assistance in automating the possible merge on web.config, assuming you want that automated.

MSBuild is great, except for one minor (or major depending on your point of view) flaw. It rebuilds the binaries every time you run a build. This means, for deploying from TEST to PRODUCTION, or STAGE to PRODUCTION (or whatever your pre-production environment is called), if you use MSBuild, you are not promoting existing binaries from one environment to the next, you are re-building them. This also means that you are relying, with certainty, that NOTHING has changed in the source code repository since you did an MSBuild to your pre-production environment. Allowing even the slightest chance of a change to anything, major or minor, means you will not be promoting a fully tested product into your production environment. In the places I work, that is not an acceptable risk.

Enter Robocopy. With Robocopy, you are copying a (hopefully) fully tested product to your production environment. You would then either need to manually modify your web.config/app.config to reflect the production environment, OR use a transformation tool to do that. I have been using the "Configuration Transformation Tool" available on SourceForge for that purpose - it works just like the MSBuild web/app.config transformations.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top