Wie stellen Sie Ihre ASP.NET-Anwendungen auf Live-Servern bereit?

Ich suche nach verschiedenen Techniken / Tools, die Sie zum Bereitstellen eines ASP.NET-Webanwendungsprojekts ( NICHT der ASP.NET-Website) für die Produktion verwenden.

Ich bin besonders an dem Workflow interessiert, der zwischen dem Zeitpunkt, zu dem Ihr Continuous Integration Build-Server die Binärdateien an einem bestimmten Ort löscht, und dem Zeitpunkt, zu dem die erste Benutzeranforderung diese Binärdateien erreicht, stattfindet.

1. Verwenden Sie bestimmte Tools oder nur XCOPY? Wie ist die Anwendung verpackt (ZIP, MSI, ...)?

2. Wie richten Sie den App-Pool und das virtuelle Verzeichnis ein, wenn eine Anwendung zum ersten Mal bereitgestellt wird (erstellen Sie sie manuell oder mit einem Tool)?

3. Wenn sich eine statische Ressource ändert (CSS, JS oder Image-Datei), stellen Sie die gesamte Anwendung oder nur die geänderte Ressource erneut bereit? Wie wäre es, wenn sich eine Assembly- / ASPX-Seite ändert?

4. Behalten Sie alle bereitgestellten Versionen für eine bestimmte Anwendung im Auge und haben Sie Verfahren, um die Anwendung auf einen zuvor bekannten Arbeitszustand zurückzusetzen, falls etwas schief geht?

Fühlen Sie sich frei, die vorherige Liste zu vervollständigen.

Und hier ist, was wir zum Bereitstellen unserer ASP.NET-Anwendungen verwenden:

1. Wir fügen der Lösung ein Web Deployment-Projekt hinzu und richten es zum Erstellen der ASP.NET-Webanwendung ein
2. Wir fügen der Lösung ein Setup-Projekt ( NICHT Web-Setup-Projekt) hinzu und legen fest, dass es die Ausgabe des Web-Bereitstellungsprojekts übernimmt
3. Wir fügen eine benutzerdefinierte Installationsaktion hinzu und führen im OnInstall-Ereignis eine benutzerdefinierte Build-.NET-Assembly aus, die mithilfe von System.DirectoryServices.DirectoryEntry einen App-Pool und ein virtuelles Verzeichnis in IIS erstellt. (Diese Aufgabe wird nur ausgeführt, wenn eine Anwendung zum ersten Mal bereitgestellt wird.) . Wir unterstützen mehrere Websites in IIS, Authentifizierung für virtuelle Verzeichnisse und Festlegen von Identitäten für App-Pools.
4. Wir fügen eine benutzerdefinierte Aufgabe in TFS hinzu, um das Setup-Projekt zu erstellen (TFS unterstützt keine Setup-Projekte, daher mussten wir devenv.exe zum Erstellen des MSI verwenden).
5. Das MSI wird auf dem Live-Server installiert (wenn es eine frühere Version des MSI gibt, wird es zuerst deinstalliert).

Wir haben unseren gesamten Code in MSIs mithilfe von Setup Factory bereitgestellt. Wenn sich etwas ändern muss, stellen wir die gesamte Lösung erneut bereit. Dies klingt nach einem Overkill für eine CSS-Datei, hält jedoch absolut alle Umgebungen synchron und wir wissen genau, was in der Produktion ist (wir stellen sie auf alle Test- und UAT-Umgebungen auf die gleiche Weise bereit).

Wir führen eine fortlaufende Bereitstellung auf den Live-Servern durch, sodass wir keine Installationsprojekte verwenden. Wir haben so etwas wie CI:

• "Live" Build-Server-Builds aus der genehmigten Quelle (nicht der "HEAD" des Repos)
• (nachdem es ein Backup gemacht hat ;-p)
• Robocopy wird auf einem Staging-Server veröffentlicht ("live", jedoch nicht im F5-Cluster).
• Die endgültige Validierung erfolgt auf dem Staging-Server, häufig mit "Hosts" -Hacks, um das Ganze so genau wie möglich zu emulieren
• robocopy / L wird automatisch verwendet, um eine Liste der Änderungen beim nächsten "Push" zu verteilen, um auf eventuelle Fehler aufmerksam zu machen
• Als Teil eines geplanten Prozesses wird der Cluster durchlaufen und per Robocopy auf den Knoten im Cluster bereitgestellt (während sie sich außerhalb des Clusters befinden).

robocopy stellt automatisch sicher, dass nur Änderungen bereitgestellt werden.

Bezüglich des App-Pools usw.; Ich würde es lieben , wenn dies automatisiert würde ( siehe diese Frage ), aber im Moment ist es manuell. Das möchte ich aber wirklich ändern.

(Es hilft wahrscheinlich, dass wir ein eigenes Rechenzentrum und eine eigene Serverfarm "vor Ort" haben, sodass wir nicht viele Hürden überwinden müssen.)

Webseite

Bereitsteller: http://www.codeproject.com/KB/install/deployer.aspx

Ich veröffentliche die Website in einem lokalen Ordner, komprimiere sie und lade sie dann über FTP hoch. Deployer auf dem Server extrahiert dann zip, ersetzt Konfigurationswerte (in Web.Config und anderen Dateien) und fertig.

Natürlich müssen Sie für die erste Ausführung eine Verbindung zum Server herstellen und die IIS-WebSite-Datenbank einrichten, aber danach ist das Veröffentlichen von Updates ein Kinderspiel.

Datenbank

Um Datenbanken synchron zu halten, verwende ich http://www.red-gate.com/products/sql-development/sql-compare/

Wenn sich der Server hinter einer Reihe von Routern befindet und Sie keine direkte Verbindung herstellen können (was für SQL Compare erforderlich ist), verwenden Sie https://secure.logmein.com/products/hamachi2/ , um ein VPN zu erstellen.

Ich stelle hauptsächlich ASP.NET-Apps auf Linux-Servern bereit und stelle alles für die kleinste Änderung erneut bereit. Hier ist mein Standard-Workflow:

• Ich benutze ein Quellcode-Repository (wie Subversion)
• Auf dem Server habe ich ein Bash-Skript, das Folgendes ausführt:
  • Checkt den neuesten Code aus
  • Macht einen Build (erstellt die DLLs)
  • Filtert die Dateien auf das Wesentliche herunter (entfernt beispielsweise Codedateien)
  • Sichert die Datenbank
  • Stellt die Dateien auf dem Webserver in einem Verzeichnis bereit, das mit dem aktuellen Datum benannt ist
  • Aktualisiert die Datenbank, wenn ein neues Schema in der Bereitstellung enthalten ist
  • Macht die neue Installation zur Standardinstallation, damit sie beim nächsten Treffer bereitgestellt wird

Das Auschecken erfolgt mit der Befehlszeilenversion von Subversion und das Erstellen erfolgt mit xbuild (msbuild funktioniert ähnlich wie im Mono-Projekt). Der größte Teil der Magie wird in ReleaseIt ausgeführt.

Auf meinem Entwicklungsserver habe ich im Wesentlichen eine kontinuierliche Integration, aber auf der Produktionsseite habe ich tatsächlich SSH in den Server und initiiere die Bereitstellung manuell, indem ich das Skript ausführe. Mein Skript heißt geschickt 'deploy', also tippe ich es an der Bash-Eingabeaufforderung. Ich bin sehr kreativ Nicht.

In der Produktion muss ich zweimal 'deploy' eingeben: einmal zum Auschecken, Erstellen und Bereitstellen in einem datierten Verzeichnis und einmal, um dieses Verzeichnis zur Standardinstanz zu machen. Da die Verzeichnisse datiert sind, kann ich zu jeder vorherigen Bereitstellung zurückkehren, indem ich einfach 'deploy' aus dem entsprechenden Verzeichnis eingebe.

Die Erstbereitstellung dauert einige Minuten und die Umstellung auf eine frühere Version einige Sekunden.

Es war eine gute Lösung für mich und basiert nur auf den drei Befehlszeilenprogrammen (svn, xbuild und releaseit), dem DB-Client, SSH und Bash.

Ich muss die Kopie von ReleaseIt auf CodePlex wirklich irgendwann aktualisieren:

http://releaseit.codeplex.com/

Einfache XCopy für ASP.NET. Zip es hoch, sftp zum Server, extrahiere an den richtigen Ort. Bei der ersten Bereitstellung wird IIS manuell eingerichtet

Beantwortung Ihrer Fragen:

1. XCopy
2. Manuell
3. Für statische Ressourcen stellen wir nur die geänderte Ressource bereit.
   Für DLLs stellen wir die geänderten DLL- und ASPX-Seiten bereit.
4. Ja und ja.

Es schön und einfach zu halten, hat uns bisher viele Kopfschmerzen erspart.

Verwenden Sie bestimmte Tools oder nur XCOPY? Wie ist die Anwendung verpackt (ZIP, MSI, ...)?

Als Entwickler für BuildMaster verwende ich dies natürlich. Alle Anwendungen werden im Tool als Artefakte erstellt und verpackt, die intern als ZIP-Dateien gespeichert werden.

Wie richten Sie den App-Pool und das virtuelle Verzeichnis ein, wenn eine Anwendung zum ersten Mal bereitgestellt wird (erstellen Sie sie manuell oder mit einem Tool)?

Manuell - Wir erstellen eine Änderungskontrolle innerhalb des Tools, die uns an die genauen Schritte erinnert, die in zukünftigen Umgebungen ausgeführt werden müssen, wenn sich die Anwendung durch ihre Testumgebungen bewegt. Dies könnte auch mit einem einfachen PowerShell-Skript automatisiert werden. Wir fügen jedoch nicht sehr oft neue Anwendungen hinzu, sodass die 1-minütige manuelle Erstellung der Site genauso einfach ist.

Wenn sich eine statische Ressource ändert (CSS, JS oder Image-Datei), stellen Sie die gesamte Anwendung oder nur die geänderte Ressource erneut bereit? Wie wäre es, wenn sich eine Assembly- / ASPX-Seite ändert?

Standardmäßig ist der Prozess zum Bereitstellen von Artefakten so eingerichtet, dass nur geänderte Dateien auf den Zielserver übertragen werden. Dies umfasst alles von CSS-Dateien, JavaScript-Dateien, ASPX-Seiten und verknüpften Assemblys.

Behalten Sie alle bereitgestellten Versionen für eine bestimmte Anwendung im Auge und haben Sie Verfahren, um die Anwendung auf einen zuvor bekannten Arbeitszustand zurückzusetzen, falls etwas schief geht?

Ja, BuildMaster erledigt das alles für uns. Das Wiederherstellen ist meistens so einfach wie das erneute Ausführen einer alten Build-Heraufstufung. Manchmal müssen Datenbankänderungen jedoch manuell wiederhergestellt werden, und es kann zu Datenverlust kommen. Der grundlegende Rollback-Prozess wird hier detailliert beschrieben: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

Web-Setup / Installationsprojekte - so können Sie es einfach deinstallieren, wenn etwas schief geht

Unfold ist eine Capistrano-ähnliche Bereitstellungslösung, die ich für .net-Anwendungen geschrieben habe. Es ist das, was wir für alle unsere Projekte verwenden, und es ist eine sehr flexible Lösung. Es löst die meisten typischen Probleme für .net-Anwendungen, wie in diesem Blog-Beitrag von Rob Conery erläutert.

• Es kommt mit einem guten "Standard" -Verhalten in dem Sinne, dass es viele Standardaufgaben für Sie erledigt: Abrufen des Codes aus der Quellcodeverwaltung, Erstellen, Erstellen des Anwendungspools, Einrichten von IIS usw.
• Releases basierend auf der Quellcodeverwaltung
• Es verfügt über Task-Hooks , sodass das Standardverhalten leicht erweitert oder geändert werden kann
• es hat Rollback
• Es ist alles Powershell , also gibt es keine externen Abhängigkeiten
• Es verwendet Powershell-Remoting, um auf Remotecomputer zuzugreifen

Hier ist eine Einführung und einige andere Blog-Beiträge.

Um die obigen Fragen zu beantworten:

• Wie ist die Anwendung verpackt (ZIP, MSI, ...)?

  Git (oder ein anderer scm) ist die Standardmethode, um die Anwendung auf dem Zielcomputer abzurufen. Alternativ können Sie einen lokalen Build durchführen und das Ergebnis über die Powereshell-Remoting-Verbindung kopieren

• Wie richten Sie den App-Pool und das virtuelle Verzeichnis ein, wenn eine Anwendung zum ersten Mal bereitgestellt wird (erstellen Sie sie manuell oder mit einem Tool)?

  Unfold konfiguriert den Anwendungspool und die Website-Anwendung mithilfe des WebAdministration-Moduls von Powershell. Es ermöglicht uns (und Ihnen), jeden Aspekt des Anwendungspools oder der Website zu ändern

• Wenn sich eine statische Ressource ändert (CSS, JS oder Image-Datei), stellen Sie die gesamte Anwendung oder nur die geänderte Ressource erneut bereit? Wie wäre es, wenn sich eine Assembly- / ASPX-Seite ändert?

  Ja, entfaltet dies, jede Bereitstellung wird neben den anderen installiert. Auf diese Weise können wir leicht einen Rollback durchführen, wenn etwas schief geht. Außerdem können wir eine bereitgestellte Version problemlos auf eine Versionskontrolle zurückführen.

• Verfolgen Sie alle bereitgestellten Versionen für eine bestimmte Anwendung?

  Ja, entfalten hält alte Versionen herum. Nicht alle Versionen, aber eine Reihe von Versionen. Es macht das Zurückrollen fast trivial.

Wir haben unseren Veröffentlichungsprozess im letzten Jahr verbessert und jetzt haben wir es geschafft. Ich verwende Jenkins, um alle unsere automatisierten Builds und Releases zu verwalten, aber ich bin sicher, dass Sie TeamCity oder CruiseControl verwenden können.

Beim Einchecken führt unser "normaler" Build Folgendes aus:

• Jenkins führt ein SVN-Update durch, um die neueste Version des Codes abzurufen
• Eine NuGet-Paketwiederherstellung wird für unser eigenes lokales NuGet-Repository ausgeführt
• Die Anwendung wird mit MsBuild kompiliert. Das Einrichten ist ein Abenteuer, da Sie die richtige MsBuild und dann die ASP.NET- und MVC-DLLs auf Ihrer Build-Box installieren müssen. (Als Randnotiz: Als ich <MvcBuildViews>true</MvcBuildViews>meine .csproj-Dateien eingegeben hatte, um die Ansichten zu kompilieren, stürzte msbuild zufällig ab, sodass ich es deaktivieren musste.)
• Sobald der Code kompiliert ist, werden die Komponententests ausgeführt (ich verwende nunit dafür, aber Sie können alles verwenden, was Sie wollen).
• Wenn alle Komponententests bestanden sind, stoppe ich den IIS-App-Pool, stelle die App lokal bereit (nur ein paar grundlegende XCOPY-Befehle zum Kopieren der erforderlichen Dateien) und starte dann IIS neu (ich hatte Probleme mit IIS-Sperrdateien, und dies wurde behoben es)
• Ich habe separate web.config-Dateien für jede Umgebung. dev, uat, prod. (Ich habe versucht, das Web-Transformationsmaterial mit wenig Erfolg zu verwenden). Daher wird auch die richtige Datei web.config kopiert
• Ich benutze dann PhantomJS, um eine Reihe von UI-Tests durchzuführen. Außerdem werden eine Reihe von Screenshots mit unterschiedlichen Auflösungen (Mobil, Desktop) erstellt und jeder Screenshot mit einigen Informationen (Seitentitel, Auflösung) versehen. Jenkins unterstützt diese Screenshots hervorragend und sie werden als Teil des Builds gespeichert
• Sobald die Integrations-UI-Tests bestanden sind, ist der Build erfolgreich

Wenn jemand auf "Für UAT bereitstellen" klickt:

• Wenn der letzte Build erfolgreich war, führt Jenkins ein weiteres SVN-Update durch
• Die Anwendung wird mithilfe einer RELEASE-Konfiguration kompiliert
• Ein "www" -Verzeichnis wird erstellt und die Anwendung in dieses Verzeichnis kopiert
• Ich benutze dann Winscp, um das Dateisystem zwischen der Build-Box und UAT zu synchronisieren
• Ich sende eine HTTP-Anfrage an den UAT-Server und stelle sicher, dass ich eine 200 zurück bekomme
• Diese Revision ist in SVN als UAT-datetime gekennzeichnet
• Wenn wir so weit sind, ist der Build erfolgreich!

Wenn wir auf "Deploy to Prod" klicken:

• Der Benutzer wählt ein zuvor erstelltes UAT-Tag aus
• Das Tag wird auf "umgeschaltet"
• Code wird kompiliert und mit dem Prod-Server synchronisiert
• HTTP-Anfrage an Prod Server
• Diese Revision ist in SVN als Prod-datetime gekennzeichnet
• Die Version wird komprimiert und gespeichert

Alles in allem dauert ein vollständiger Build bis zur Produktion ungefähr 30 Sekunden, mit denen ich sehr, sehr zufrieden bin.

Vorteile dieser Lösung:

• Es ist schnell
• Unit-Tests sollten logische Fehler erkennen
• Wenn ein UI-Fehler in die Produktion kommt, zeigen die Screenshots hoffentlich, welche Revision # ihn verursacht hat
• UAT und Prod werden synchron gehalten
• Jenkins zeigt Ihnen eine großartige Release-Historie für UAT und Prod mit allen Commit-Nachrichten
• UAT- und Prod-Releases werden automatisch markiert
• Sie können sehen, wann Veröffentlichungen stattfinden und wer sie durchgeführt hat

Die Hauptnachteile dieser Lösung sind:

• Wann immer Sie eine Version für Prod machen, müssen Sie eine Version für UAT machen. Dies war eine bewusste Entscheidung, die wir getroffen haben, weil wir immer sicherstellen wollten, dass UAT mit Prod immer auf dem neuesten Stand ist. Trotzdem ist es ein Schmerz.
• Es gibt einige Konfigurationsdateien. Ich habe versucht, alles in Jenkins zu haben, aber es werden einige Support-Batch-Dateien als Teil des Prozesses benötigt. (Diese sind auch eingecheckt).
• DB-Upgrade- und Downgrade-Skripte sind Teil der App und werden beim Start der App ausgeführt. Es funktioniert (meistens), aber es ist ein Schmerz.

Ich würde gerne weitere mögliche Verbesserungen hören!

Im Jahr 2009, als diese Antwort stammt, haben wir CruiseControl.net für unsere Builds zur kontinuierlichen Integration verwendet, die auch Release Media ausgaben.

Von dort aus haben wir die Smart Sync-Software verwendet , um sie mit einem Produktionsserver zu vergleichen, der sich außerhalb des Lastausgleichspools befand, und die Änderungen nach oben verschoben.

Nach der Validierung der Version haben wir schließlich ein DOS-Skript ausgeführt, das hauptsächlich RoboCopy verwendete, um den Code mit den Live-Servern zu synchronisieren und IIS sofort zu stoppen / zu starten.

Bei der letzten Firma, für die ich gearbeitet habe, haben wir eine rSync-Batchdatei bereitgestellt, um nur die Änderungen seit dem letzten Upload hochzuladen. Das Schöne an rSync ist, dass Sie Ausschlusslisten hinzufügen können, um bestimmte Dateien oder Dateinamenmuster auszuschließen. So ist es zum Beispiel sehr einfach, alle unsere CS-Dateien, Lösungs- und Projektdateien auszuschließen.

Wir haben TortoiseSVN für die Versionskontrolle verwendet, und daher war es schön, mehrere SVN-Befehle schreiben zu können, um Folgendes zu erreichen:

• Überprüfen Sie zunächst, ob der Benutzer über die neueste Version verfügt. Wenn nicht, fordern Sie sie entweder zum Update auf oder führen Sie das Update sofort aus.
• Laden Sie eine Textdatei vom Server mit dem Namen "synclog.txt" herunter, in der angegeben ist, wer der SVN-Benutzer ist, welche Versionsnummer er hochlädt und Datum und Uhrzeit des Uploads. Fügen Sie eine neue Zeile für den aktuellen Upload hinzu und senden Sie sie zusammen mit den geänderten Dateien an den Server zurück. Auf diese Weise können Sie ganz einfach herausfinden, auf welche Version der Website Sie zurücksetzen können, wenn die Wahrscheinlichkeit besteht, dass ein Upload Probleme verursacht.

Darüber hinaus gibt es eine zweite Batch-Datei, die nur auf dem Live-Server nach Dateidifferenzen sucht. Dies kann das häufig auftretende Problem hervorheben, bei dem jemand seine Änderungen hochlädt, aber nicht an SVN festschreibt. In Kombination mit dem oben erwähnten Synchronisierungsprotokoll konnten wir herausfinden, wer der wahrscheinliche Schuldige war, und sie bitten, ihre Arbeit zu begehen.

Und schließlich können Sie mit rSync eine Sicherungskopie der Dateien erstellen, die beim Hochladen ersetzt wurden. Wir haben sie in einen Sicherungsordner verschieben lassen. Wenn Sie also plötzlich feststellen, dass einige der Dateien nicht überschrieben werden sollten, finden Sie die letzte Sicherungsversion jeder Datei in diesem Ordner.

Während sich die Lösung zu der Zeit etwas klobig anfühlte, habe ich sie seitdem viel mehr zu schätzen gelernt, wenn ich in Umgebungen arbeite, in denen die Upload-Methode viel weniger elegant oder einfach ist (z. B. Remotedesktop, Kopieren und Einfügen der gesamten Site). .

Ich würde empfehlen, NICHT nur vorhandene Anwendungsdateien zu überschreiben, sondern stattdessen ein Verzeichnis pro Version zu erstellen und die IIS-Anwendung dem neuen Pfad zuzuordnen. Dies hat mehrere Vorteile:

• Bei Bedarf schnell zurücksetzen
• Sie müssen IIS oder den App-Pool nicht stoppen, um Sperrprobleme zu vermeiden
• Kein Risiko, dass alte Dateien Probleme verursachen
• Mehr oder weniger Ausfallzeiten (normalerweise nur eine Pause bei der Initialisierung der neuen Appdomain)

Das einzige Problem, das wir hatten, ist das Zwischenspeichern von Ressourcen, wenn Sie den App-Pool nicht neu starten und sich auf den automatischen Appdomain-Wechsel verlassen.