Strategien zur Datenbankentwicklung und -bereitstellung (VB)

von Scott Mitchell

Wenn Sie eine datengesteuerte Anwendung zum ersten Mal bereitstellen, können Sie die Datenbank in der Entwicklungsumgebung blind in die Produktionsumgebung kopieren. Das Ausführen einer blinden Kopie in nachfolgenden Bereitstellungen überschreibt jedoch alle Daten, die in die Produktionsdatenbank eingegeben werden. Beim Bereitstellen einer Datenbank werden stattdessen die Änderungen, die seit der letzten Bereitstellung an der Entwicklungsdatenbank vorgenommen wurden, auf die Produktionsdatenbank angewendet. In diesem Tutorial werden diese Herausforderungen untersucht und verschiedene Strategien zur Unterstützung bei der Chronifizierung und Anwendung der Seit der letzten Bereitstellung vorgenommenen Änderungen an der Datenbank bereitgestellt.

Einführung

Wie in den vorherigen Tutorials erläutert, beinhaltet die Bereitstellung einer ASP.NET Anwendung das Kopieren der relevanten Inhalte aus der Entwicklungsumgebung in die Produktionsumgebung. Die Bereitstellung ist kein einmaliges Ereignis, sondern ein Ereignis, das jedes Mal auftritt, wenn eine neue Version der Software veröffentlicht wird oder wenn Fehler oder Sicherheitsbedenken erkannt und behoben wurden. Beim Kopieren ASP.NET Seiten, Images, JavaScript-Dateien und anderer solcher Dateien in die Produktionsumgebung müssen Sie sich nicht darum kümmern, wie diese Datei seit der letzten Bereitstellung geändert wurde. Sie können die Datei blind in die Produktion kopieren und den vorhandenen Inhalt überschreiben. Leider erstreckt sich diese Einfachheit nicht auf die Bereitstellung der Datenbank.

Wenn Sie eine datengesteuerte Anwendung zum ersten Mal bereitstellen, können Sie die Datenbank in der Entwicklungsumgebung blind in die Produktionsumgebung kopieren. Das Ausführen einer blinden Kopie in nachfolgenden Bereitstellungen überschreibt jedoch alle Daten, die in die Produktionsdatenbank eingegeben werden. Beim Bereitstellen einer Datenbank werden stattdessen die Änderungen , die seit der letzten Bereitstellung an der Entwicklungsdatenbank vorgenommen wurden, auf die Produktionsdatenbank angewendet. In diesem Tutorial werden diese Herausforderungen untersucht und verschiedene Strategien zur Unterstützung bei der Chronifizierung und Anwendung der Seit der letzten Bereitstellung vorgenommenen Änderungen an der Datenbank bereitgestellt.

Herausforderungen bei der Bereitstellung einer Datenbank

Bevor eine datengesteuerte Anwendung zum ersten Mal bereitgestellt wurde, gibt es nur eine Datenbank, nämlich die Datenbank in der Entwicklungsumgebung. Deshalb können Sie beim erstmaligen Bereitstellen einer datengesteuerten Anwendung die Datenbank in der Entwicklungsumgebung blind in die Produktionsumgebung kopieren. Sobald die Anwendung bereitgestellt wurde, gibt es jedoch zwei Kopien der Datenbank: eine in der Entwicklung und eine in der Produktion.

Zwischen bereitstellungen können entwicklungs- und produktionsdatenbanken nicht mehr synchronisiert werden. Während das Schema der Produktionsdatenbank unverändert bleibt, kann sich das Schema der Entwicklungsdatenbank ändern, wenn neue Features hinzugefügt werden. Sie können Spalten, Tabellen, Ansichten oder gespeicherte Prozeduren hinzufügen oder entfernen. Möglicherweise werden auch wichtige Daten zur Entwicklungsdatenbank hinzugefügt. Viele datengesteuerte Anwendungen enthalten Nachschlagetabellen, die mit hartcodierten, anwendungsspezifischen Daten gefüllt sind, die nicht vom Benutzer bearbeitet werden können. Beispielsweise kann eine Auktionswebsite über eine Dropdownliste mit Optionen verfügen, die die Bedingung des versteigerten Elements beschreiben: Neu, Wie neu, gut und Fair. Anstatt diese Optionen direkt in der Dropdownliste zu codieren, ist es in der Regel besser, sie in einer Datenbanktabelle zu platzieren. Wenn während der Entwicklung der Tabelle eine neue Bedingung mit dem Namen Poor hinzugefügt wird, muss bei der Bereitstellung der Anwendung dieser Datensatz der Nachschlagetabelle in der Produktionsdatenbank hinzugefügt werden.

Im Idealfall würde die Bereitstellung der Datenbank das Kopieren der Datenbank aus der Entwicklung in die Produktion erfordern. Beachten Sie jedoch, dass die Produktionsdatenbank nach der Bereitstellung der Anwendung und der Fortgesetzten Entwicklung mit echten Daten von echten Benutzern aufgefüllt wird. Wenn Sie also die Datenbank bei der nächsten Bereitstellung einfach aus der Entwicklung in die Produktion kopieren würden, würden Sie die Produktionsdatenbank überschreiben und ihre vorhandenen Daten verlieren. Das Nettoergebnis besteht darin, dass die Bereitstellung der Datenbank auf das Anwenden der Seit der letzten Bereitstellung vorgenommenen Änderungen an der Entwicklungsdatenbank beschränkt ist.

Da bei der Bereitstellung einer Datenbank die Änderungen im Schema und möglicherweise die Daten seit der letzten Bereitstellung angewendet werden, muss ein Änderungsverlauf beibehalten (oder zur Bereitstellungszeit bestimmt werden), damit diese Änderungen auf die Produktion angewendet werden können. Es gibt eine Vielzahl von Techniken zum Verwalten und Anwenden von Änderungen am Datenmodell.

Definieren der Baseline

Um die Änderungen an der Anwendungsdatenbank beizubehalten, benötigen Sie einen Startzustand, eine Baseline, auf die die Änderungen angewendet werden. Bei einem Extrem kann der Startzustand eine leere Datenbank ohne Tabellen, Ansichten oder gespeicherte Prozeduren sein. Eine solche Baseline führt zu einem umfangreichen Änderungsprotokoll, da es die Erstellung aller Tabellen, Ansichten und gespeicherten Prozeduren der Datenbank sowie alle Änderungen umfassen muss, die nach der ersten Bereitstellung vorgenommen wurden. Am anderen Ende des Spektrums können Sie die Baseline als Version der Datenbank festlegen, die ursprünglich in der Produktionsumgebung bereitgestellt wird. Diese Auswahl führt zu einem viel kleineren Änderungsprotokoll, da es nur die Änderungen enthält, die nach der ersten Bereitstellung an der Datenbank vorgenommen wurden. Dies ist der Ansatz, den ich bevorzuge. Und natürlich können Sie einen ansatz mehr in der Mitte der Straße wählen, indem Sie die Baseline als einen Punkt zwischen der anfänglichen Erstellung der Datenbank und dem Zeitpunkt definieren, an dem die Datenbank zum ersten Mal bereitgestellt wird.

Nachdem Sie eine Baseline ausgewählt haben, sollten Sie ein SQL-Skript generieren, das ausgeführt werden kann, um die Baselineversion neu zu erstellen. Ein solches Skript ermöglicht es, die Basisversion der Datenbank schnell neu zu erstellen. Diese Funktionalität ist besonders nützlich in größeren Projekten, in denen möglicherweise mehrere Entwickler am Projekt oder zusätzliche Umgebungen wie Tests oder Staging arbeiten, die jeweils eine eigene Kopie der Datenbank benötigen.

Es stehen Ihnen eine Vielzahl von Tools zur Verfügung, um ein SQL-Skript der Baselineversion zu generieren. In SQL Server Management Studio (SSMS) können Sie mit der rechten Maustaste auf die Datenbank klicken, zum Untermenü Aufgaben wechseln und die Option Skripts generieren auswählen. Dadurch wird der Skript-Assistent gestartet, den Sie anweisen können, eine Datei zu generieren, die die SQL-Befehle zum Erstellen von Datenbankobjekten enthält. Eine weitere Option ist der Datenbankveröffentlichungs-Assistent, der die SQL-Befehle generieren kann, um nicht nur das Datenbankschema, sondern auch die Daten in den Datenbanktabellen zu erstellen. Der Datenbankveröffentlichungs-Assistent wurde im Tutorial Bereitstellen einer Datenbank ausführlich untersucht. Unabhängig davon, welches Tool Sie verwenden, sollten Sie letztendlich über eine Skriptdatei verfügen, die Sie verwenden können, um die Baselineversion Ihrer Datenbank neu zu erstellen, falls dies erforderlich ist.

Dokumentieren der Datenbankänderungen in Prose

Die einfachste Möglichkeit zum Verwalten eines Protokolls mit Änderungen am Datenmodell während der Entwicklungsphase besteht darin, die Änderungen in der Prosa aufzuzeichnen. Wenn Sie beispielsweise während der Entwicklung einer bereits bereitgestellten Anwendung der Tabelle eine neue Spalte Employees hinzufügen, eine Spalte aus der Orders Tabelle entfernen und eine neue Tabelle hinzufügen (ProductCategories), würden Sie eine Textdatei oder ein Microsoft Word Dokument mit dem folgenden Verlauf beibehalten:

Änderungsdatum	Details ändern
2009-02-03:	Spalte DepartmentID (int, NOT NULL) zur Employees Tabelle hinzugefügt. Eine Fremdschlüsseleinschränkung von Departments.DepartmentID zu Employees.DepartmentIDhinzugefügt.
2009-02-05:	Spalte TotalWeight aus der Orders Tabelle entfernt. Daten, die bereits in zugeordneten OrderDetails Datensätzen erfasst wurden.
2009-02-12:	ProductCategories Die Tabelle wurde erstellt. Es gibt drei Spalten: ProductCategoryID (int, , NOT NULLIDENTITY), CategoryName (nvarchar(50), NOT NULL) und Active (bit, NOT NULL). Eine Primärschlüsseleinschränkung wurde hinzugefügt ProductCategoryID, und der Standardwert 1 zu Active.

Dieser Ansatz hat eine Reihe von Nachteilen. Für den Anfang gibt es keine Hoffnung auf Automatisierung. Wenn diese Änderungen auf eine Datenbank angewendet werden müssen , z. B. bei der Bereitstellung der Anwendung, muss ein Entwickler jede Änderung einzeln manuell implementieren. Wenn Sie außerdem eine bestimmte Version der Datenbank aus der Baseline mithilfe des Änderungsprotokolls rekonstruieren müssen, dauert dies mehr und mehr Zeit, wenn die Größe des Protokolls zunimmt. Ein weiterer Nachteil dieser Methode ist, dass die Klarheit und Detailebene jedes Änderungsprotokolleintrags der Person überlassen wird, die die Änderung protokolliert. In einem Team mit mehreren Entwicklern können einige detailliertere, lesbarere oder präzisere Einträge als andere erstellen. Auch Tippfehler und andere menschlichen Dateneingabefehler sind möglich.

Der Hauptvorteil der Dokumentation der Datenbankänderungen in der Prosa ist die Einfachheit. Sie benötigen keine Kenntnisse mit der SQL-Syntax zum Erstellen und Ändern von Datenbankobjekten. Stattdessen können Sie die Änderungen in Der Prosa aufzeichnen und über SQL Server Management Studio grafische Benutzeroberfläche implementieren.

Das Verwalten Ihres Änderungsprotokolls in Prosa ist zugegebenermaßen nicht sehr anspruchsvoll und funktioniert nicht gut mit bestimmten Projekten, z. B. projekten mit großem Umfang, häufigen Änderungen am Datenmodell oder mehreren Entwicklern. Ich habe jedoch gesehen, dass dieser Ansatz in kleinen Ein-Mann-Projekten, die nur gelegentlich Änderungen am Datenmodell aufweisen, sehr gut funktioniert und bei denen der Soloentwickler nicht über einen starken Hintergrund in der SQL-Syntax zum Erstellen und Ändern von Datenbankobjekten verfügt.

Hinweis

Während die Informationen im Änderungsprotokoll technisch nur bis zur Bereitstellungszeit benötigt werden, empfehle ich, einen Verlauf der Änderungen zu speichern. Anstatt jedoch eine einzelne, ständig wachsende Änderungsprotokolldatei zu verwalten, sollten Sie eine andere Änderungsprotokolldatei für jede Datenbankversion in Erwägung ziehen. In der Regel sollten Sie die Datenbank bei jeder Bereitstellung versionieren. Indem Sie ein Protokoll mit Änderungsprotokollen verwalten, können Sie ab der Baseline eine beliebige Datenbankversion neu erstellen, indem Sie die Änderungsprotokollskripts ab Version 1 ausführen und fortfahren, bis Sie die Version erreichen, die Sie neu erstellen müssen.

Aufzeichnen der SQL-Änderungsanweisungen

Der Hauptnachteil der Verwaltung des Änderungsprotokolls in Prosa ist die fehlende Automatisierung. Im Idealfall ist das Implementieren der Datenbankänderungen an der Produktionsdatenbank zur Bereitstellungszeit so einfach wie das Klicken auf eine Schaltfläche zum Ausführen eines Skripts, anstatt eine Liste mit Anweisungen manuell ausführen zu müssen. Eine solche Automatisierung ist möglich, indem ein Änderungsprotokoll verwaltet wird, das die SQL-Befehle enthält, die zum Ändern des Datenmodells verwendet werden.

Die SQL-Syntax enthält eine Reihe von Anweisungen zum Erstellen und Ändern verschiedener Datenbankobjekte. Beispielsweise erstellt die CREATE TABLE-Anweisung bei Ausführung eine neue Tabelle mit den angegebenen Spalten und Einschränkungen. Die ALTER TABLE-Anweisung ändert eine vorhandene Tabelle und fügt deren Spalten oder Einschränkungen hinzu, entfernt oder ändert sie. Es gibt auch Anweisungen zum Erstellen, Ändern und Löschen von Indizes, Ansichten, benutzerdefinierten Funktionen, gespeicherten Prozeduren, Triggern und anderen Datenbankobjekten.

Kehren Sie zu unserem vorherigen Beispiel zurück, dass Sie während der Entwicklung einer bereits bereitgestellten Anwendung der Employees Tabelle eine neue Spalte hinzufügen, eine Spalte aus der Orders Tabelle entfernen und eine neue TabelleProductCategories () hinzufügen. Solche Aktionen führen zu einer Änderungsprotokolldatei mit den folgenden SQL-Befehlen:

-- Add the DepartmentID column 

ALTER TABLE [Employees] ADD [DepartmentID] 
int NOT NULL 

-- Add a foreign key constraint between Departments.DepartmentID and Employees.DepartmentID
ALTER TABLE [Employees] ADD 
CONSTRAINT [FK_Departments_DepartmentID]
      FOREIGN 
KEY ([DepartmentID]) 
      REFERENCES 
[Departments] ([DepartmentID]) 

-- Remove TotalWeight column from Orders
ALTER TABLE [Orders] DROP COLUMN 
[TotalWeight] 

-- Create the ProductCategories table

CREATE TABLE [ProductCategories]
(
      [ProductCategoryID] 
int IDENTITY(1,1) NOT NULL,
      [CategoryName] 
nvarchar(50) NOT NULL,
      [Active] 
bit NOT NULL CONSTRAINT [DF_ProductCategories_Active]  DEFAULT 
((1)),
      CONSTRAINT 
[PK_ProductCategories] PRIMARY KEY CLUSTERED ( [ProductCategoryID])
)

Das Pushen dieser Änderungen an die Produktionsdatenbank zur Bereitstellungszeit ist ein Vorgang mit einem Klick: Öffnen Sie SQL Server Management Studio, stellen Sie eine Verbindung mit Ihrer Produktionsdatenbank her, öffnen Sie ein Fenster Neue Abfrage, fügen Sie den Inhalt des Änderungsprotokolls ein, und klicken Sie auf Ausführen, um das Skript auszuführen.

Verwenden eines Vergleichstools zum Synchronisieren der Datenmodelle

Das Dokumentieren von Datenbankänderungen in Prosa ist einfach, aber die Implementierung der Änderungen erfordert, dass ein Entwickler jede Änderung an der Produktionsdatenbank einzeln vor nimmt. Das Dokumentieren der Änderung von SQL-Befehlen macht die Implementierung dieser Änderungen in der Produktionsdatenbank so einfach und schnell wie das Klicken auf eine Schaltfläche, erfordert jedoch das Erlernen und Beherrschen der SQL-Anweisungen und der Syntax zum Erstellen und Ändern von Datenbankobjekten. Datenbankvergleichstools nutzen das Beste aus beiden Ansätzen und verwerfen die schlechtesten.

Ein Datenbankvergleichstool vergleicht das Schema oder die Daten von zwei Datenbanken und zeigt einen Zusammenfassenden Bericht an, der zeigt, wie sich die Datenbanken unterscheiden. Anschließend können Sie mit einem Klick auf eine Schaltfläche die SQL-Befehle zum Synchronisieren eines oder mehrerer Datenbankobjekte generieren. Kurz gesagt, Sie können ein Datenbankvergleichstool verwenden, um die Entwicklungs- und Produktionsdatenbanken zur Bereitstellungszeit zu vergleichen, indem Sie eine Datei mit den SQL-Befehlen generieren, die bei Ausführung die Änderungen auf das Schema der Produktionsdatenbank anwenden, sodass sie das Schema der Entwicklungsdatenbank widerspiegelt.

Es gibt eine Vielzahl von Datenbankvergleichstools von Drittanbietern, die von vielen verschiedenen Anbietern angeboten werden. Ein beispiel hierfür ist SQL Compare von Red Gate Software. Lassen Sie uns den Prozess der Verwendung von SQL Compare durchlaufen, um die Schemas für Entwicklungs- und Produktionsdatenbanken zu vergleichen und zu synchronisieren.

Hinweis

Zum Zeitpunkt dieses Schreibens war die aktuelle Version von SQL Compare Version 7.1, wobei die Standard Edition 395 US-Dollar kostete. Sie können eine kostenlose 14-tägige Testversion herunterladen.

Wenn SQL Compare startet, wird das Dialogfeld Vergleichsprojekte geöffnet, in dem die gespeicherten SQL-Vergleichsprojekte angezeigt werden. Erstellen Sie ein neues Projekt. Dadurch wird der Projektkonfigurations-Assistent gestartet, der zur Eingabe von Informationen zu den zu vergleichenden Datenbanken auffordert (siehe Abbildung 1). Geben Sie die Informationen für die Entwicklungs- und Produktionsumgebungsdatenbanken ein.

Abbildung 1: Vergleichen der Entwicklungs- und Produktionsdatenbanken (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Hinweis

Wenn es sich bei Der Datenbank Ihrer Entwicklungsumgebung um eine SQL Express Edition-Datenbankdatei im App_Data Ordner Ihrer Website handelt, müssen Sie die Datenbank im SQL Server Express Datenbankserver registrieren, um sie aus dem in Abbildung 1 gezeigten Dialogfeld auswählen zu können. Die einfachste Möglichkeit besteht darin, SQL Server Management Studio (SSMS) zu öffnen, eine Verbindung mit dem SQL Server Express Datenbankserver herzustellen und die Datenbank anzufügen. Wenn Sie SSMS nicht auf Ihrem Computer installiert haben, können Sie die kostenlose SQL Server Management Studio herunterladen und installieren.

Zusätzlich zur Auswahl der zu vergleichenden Datenbanken können Sie auch eine Vielzahl von Vergleichseinstellungen auf der Registerkarte Optionen angeben. Eine Option, die Sie möglicherweise aktivieren möchten, ist die Option "Einschränkungs- und Indexnamen ignorieren". Erinnern Sie sich daran, dass im vorherigen Tutorial die Anwendungsdienste-Datenbankobjekte den Entwicklungs- und Produktionsdatenbanken hinzugefügt wurden. Wenn Sie das aspnet_regsql.exe Tool verwendet haben, um diese Objekte in der Produktionsdatenbank zu erstellen, werden Sie feststellen, dass sich der Primärschlüssel und die Namen eindeutiger Einschränkungen zwischen den Entwicklungs- und Produktionsdatenbanken unterscheiden. Folglich kennzeichnet SQL Compare alle Anwendungsdiensttabellen als unterschiedlich. Sie können entweder die Option "Einschränkungs- und Indexnamen ignorieren" deaktiviert lassen und die Einschränkungsnamen synchronisieren oder SQL Compare anweisen, diese Unterschiede zu ignorieren.

Nachdem Sie die zu vergleichenden Datenbanken ausgewählt haben (und die Vergleichsoptionen überprüft haben), klicken Sie auf die Schaltfläche Jetzt vergleichen, um mit dem Vergleich zu beginnen. In den nächsten Sekunden untersucht SQL Compare die Schemas der beiden Datenbanken und generiert einen Bericht über deren Unterschiede. Ich habe absichtlich einige Änderungen an der Entwicklungsdatenbank vorgenommen, um zu zeigen, wie solche Abweichungen in der SQL Compare-Schnittstelle festgestellt werden. Wie Abbildung 2 zeigt, habe ich der Authors Tabelle eine BirthDate Spalte hinzugefügt, die ISBN Spalte aus der Books Tabelle entfernt und eine neue Tabelle hinzugefügt, die es Benutzern ermöglichen soll, Ratingsdie überprüften Bücher zu bewerten.

Hinweis

Die in diesem Tutorial vorgenommenen Datenmodelländerungen wurden durchgeführt, um die Verwendung eines Datenbankvergleichstools zu veranschaulichen. Sie werden diese Änderungen in der Datenbank in zukünftigen Tutorials nicht finden.

Abbildung 2: SQL Compare Listen the Differences between the Development and Production Databases (Hier klicken, um das Bild in voller Größe anzuzeigen)

SQL Compare unterteilt die Datenbankobjekte in Gruppen und zeigt Ihnen schnell, welche Objekte in beiden Datenbanken vorhanden sind, aber unterschiedlich sind, welche Objekte in einer Datenbank vorhanden sind, aber nicht in der anderen, und welche Objekte identisch sind. Wie Sie sehen können, gibt es zwei Objekte, die in beiden Datenbanken vorhanden sind, aber unterschiedlich sind: die Tabelle, in der Authors eine Spalte hinzugefügt wurde, und die Tabelle, in der Books eines entfernt wurde. Es gibt ein Objekt, das nur in der Entwicklungsdatenbank vorhanden ist, nämlich die neu erstellte Ratings Tabelle. Und es gibt 117 Objekte, die in beiden Datenbanken identisch sind.

Wenn Sie ein Datenbankobjekt auswählen, wird das Fenster SQL-Unterschiede angezeigt, in dem angezeigt wird, wie sich diese Objekte unterscheiden. Im Fenster SQL-Unterschiede, das unten in Abbildung 2 angezeigt wird, wird hervorgehoben, dass die Authors Tabelle in der Entwicklungsdatenbank über die BirthDate Spalte verfügt, die in der Authors Tabelle in der Produktionsdatenbank nicht gefunden wird.

Nachdem Sie die Unterschiede überprüft und ausgewählt haben, welche Objekte Sie synchronisieren möchten, besteht der nächste Schritt darin, die SQL-Befehle zu generieren, die erforderlich sind, um das Schema der Produktionsdatenbank so zu aktualisieren, dass es der Entwicklungsdatenbank entspricht. Dies erfolgt über den Synchronisierungs-Assistenten. Der Synchronisierungs-Assistent bestätigt, welche Objekte synchronisiert werden sollen, und fasst den Aktionsplan zusammen (siehe Abbildung 3). Sie können die Datenbanken sofort synchronisieren oder ein Skript mit den SQL-Befehlen generieren, das in Ihrer Freizeit ausgeführt werden kann.

Abbildung 3: Verwenden des Synchronisierungs-Assistenten zum Synchronisieren ihrer Datenbankschemas (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Datenbankvergleichstools wie Red Gate Softwares SQL Compare machen das Anwenden der Änderungen am Entwicklungsdatenbankschema auf die Produktionsdatenbank so einfach wie mit Einem Klick.

Hinweis

SQL Compare vergleicht und synchronisiert zwei Datenbankschemas. Leider werden die Daten in zwei Datenbanktabellen nicht verglichen und synchronisiert. Red Gate Software bietet ein Produkt namens SQL Data Compare an, das die Daten zwischen zwei Datenbanken vergleicht und synchronisiert, aber es ist ein separates Produkt von SQL Compare und kostet weitere 395 US-Dollar.

Offline schalten der Anwendung während der Bereitstellung

Wie wir in diesen Tutorials gesehen haben, ist die Bereitstellung ein Prozess, der mehrere Schritte umfasst: Kopieren der ASP.NET Seiten, master Seiten, CSS-Dateien, JavaScript-Dateien, Bilder und anderer erforderlicher Inhalte aus der Entwicklungsumgebung in die Produktionsumgebung, Kopieren der produktionsumgebungsspezifischen Konfigurationsinformationen bei Bedarf und Anwenden der Änderungen auf das Datenmodell seit der letzten Bereitstellung. Abhängig von der Anzahl der Dateien und der Komplexität ihrer Datenbankänderungen können diese Schritte zwischen einigen Sekunden und mehreren Minuten dauern. Während dieses Fensters befindet sich die Webanwendung im Fluss, und Benutzer, die die Website besuchen, können Fehler oder unerwartetes Verhalten auftreten.

Beim Bereitstellen einer Website empfiehlt es sich, die Webanwendung bis zum Abschluss der Bereitstellung "offline" zu schalten. Die Anwendung offline zu schalten (und nach Abschluss des Bereitstellungsprozesses wieder hochzuladen) ist so einfach wie das Hochladen und Löschen einer Datei. Ab ASP.NET 2.0 wird durch das bloße Vorhandensein einer Datei namens app_offline.htm im Stammverzeichnis der Anwendung die gesamte Website offline geschaltet. Jede Anforderung an eine ASP.NET Seite auf dieser Website wird automatisch mit dem Inhalt der app_offline.htm Datei beantwortet. Sobald diese Datei entfernt wurde, wird die Anwendung wieder online geschaltet.

Das Offlinestellen einer Anwendung während der Bereitstellung ist also so einfach, wie eine app_offline.htm Datei vor Beginn des Bereitstellungsprozesses in das Stammverzeichnis der Produktionsumgebung hochzuladen und sie nach Abschluss der Bereitstellung zu löschen (oder sie in etwas anderes umzubenennen). Weitere Informationen zu dieser Technik finden Sie im Artikel von John Peterson im Artikel Offlinenehmen einer ASP.NET Anwendung.

Zusammenfassung

Die Standard Herausforderung bei der Bereitstellung einer datengesteuerten Anwendung konzentriert sich auf die Bereitstellung der Datenbank. Da es zwei Versionen der Datenbank gibt – eine in der Entwicklungsumgebung und eine in der Produktionsumgebung – können diese beiden Datenbankschemas nicht mehr synchronisiert werden, wenn neue Features in der Entwicklung hinzugefügt werden. Da die Produktionsdatenbank mit echten Daten von echten Benutzern aufgefüllt wird, können Sie die Produktionsdatenbank nicht mit der geänderten Entwicklungsdatenbank überschreiben, wie beim Bereitstellen der Dateien, aus denen die Anwendung besteht (die ASP.NET Seiten, Bilddateien usw.). Stattdessen umfasst die Bereitstellung einer Datenbank die Implementierung des genauen Satzes von Änderungen, die seit der letzten Bereitstellung an der Entwicklungsdatenbank in der Produktionsdatenbank vorgenommen wurden.

In diesem Tutorial wurden drei Techniken zum Verwalten und Anwenden eines Protokolls von Datenbankänderungen untersucht. Der einfachste Ansatz besteht darin, die Änderungen in der Prosa aufzuzeichnen. Diese Taktik macht die Implementierung dieser Änderungen in der Produktionsdatenbank zwar zu einem manuellen Prozess, erfordert jedoch keine Kenntnisse der SQL-Befehle zum Erstellen und Ändern von Datenbankobjekten. Ein komplexerer Ansatz, der in größeren Projekten oder Projekten mit mehreren Entwicklern wesentlich schmackhafter ist, besteht darin, die Änderungen als eine Reihe von SQL-Befehlen aufzuzeichnen. Dadurch wird das Rollout dieser Änderungen an der Zieldatenbank erheblich vereinfacht. Das Beste aus beiden Ansätzen kann mit einem Datenbankvergleichstool erreicht werden, z. B. Red Gate Software s SQL Compare.

Dieses Tutorial schließt unseren Fokus auf die Bereitstellung einer datengesteuerten Anwendung ab. Im nächsten Tutorial erfahren Sie, wie Sie auf Fehler in der Produktionsumgebung reagieren. Wir sehen uns an, wie sie anstelle des gelben Bildschirms des Todes eine benutzerfreundliche Fehlerseite anzeigen. Außerdem erfahren Sie, wie Sie die Fehlerdetails protokollieren und Sie benachrichtigen, wenn solche Fehler auftreten.

Viel Spaß beim Programmieren!

ZurückWeiter