Strategie vývoje a nasazení databází (C#)

Scott Mitchell

Při prvním nasazení aplikace řízené daty můžete naslepo zkopírovat databázi ve vývojovém prostředí do produkčního prostředí. Provedení slepé kopie v následných nasazeních ale přepíše všechna data zadaná do produkční databáze. Nasazení databáze místo toho zahrnuje použití změn provedených ve vývojové databázi od posledního nasazení do produkční databáze. Tento kurz zkoumá tyto výzvy a nabízí různé strategie, které vám pomůžou s kronikou a použitím změn provedených v databázi od posledního nasazení.

Úvod

Jak bylo popsáno v předchozích kurzech, nasazení aplikace ASP.NET zahrnuje zkopírování příslušného obsahu z vývojového prostředí do produkčního prostředí. Nasazení není jednorázová událost, ale spíše něco, co se stane při každém vydání nové verze softwaru nebo při zjištění a vyřešení chyb nebo problémů se zabezpečením. Při kopírování ASP.NET stránek, obrázků, souborů JavaScriptu a dalších takových souborů do produkčního prostředí se nemusíte zabývat tím, jak se tyto soubory od posledního nasazení změnily. Soubor můžete slepě zkopírovat do produkčního prostředí a přepíšete existující obsah. Tato jednoduchost se bohužel nevztahuje na nasazení databáze.

Při prvním nasazení aplikace řízené daty můžete naslepo zkopírovat databázi ve vývojovém prostředí do produkčního prostředí. Provedení slepé kopie v následných nasazeních ale přepíše všechna data zadaná do produkční databáze. Nasazení databáze místo toho zahrnuje použití změn provedených ve vývojové databázi od posledního nasazení do produkční databáze. Tento kurz zkoumá tyto výzvy a nabízí různé strategie, které vám pomůžou s kronikou a použitím změn provedených v databázi od posledního nasazení.

Výzvy spojené s nasazením databáze

Před prvním nasazením aplikace řízené daty existuje pouze jedna databáze, a to databáze ve vývojovém prostředí, což je důvod, proč při prvním nasazení aplikace řízené daty můžete databázi ve vývojovém prostředí slepě zkopírovat do produkčního prostředí. Jakmile je ale aplikace nasazená, existují dvě kopie databáze: jedna ve vývoji a jedna v produkčním prostředí.

Mezi nasazeními můžou být vývojové a produkční databáze nesynchronní. I když schéma produkční databáze zůstává beze změny, může se při přidání nových funkcí změnit schéma vývojové databáze. Můžete přidávat nebo odebírat sloupce, tabulky, zobrazení nebo uložené procedury. Do vývojové databáze se také můžou přidávat důležitá data. Mnoho aplikací řízených daty zahrnuje vyhledávací tabulky naplněné pevně zakódovanými daty specifickými pro aplikaci, která není možné upravovat uživatelem. Web aukce může mít například rozevírací seznam s možnostmi, které popisují podmínku dražené položky: Nová, Lajk nová, Dobrá a Spravedlivá. Místo pevného kódování těchto možností přímo v rozevíracím seznamu je obvykle lepší je umístit do databázové tabulky. Pokud se během vývoje přidá do tabulky nová podmínka s názvem Poor, pak se při nasazování aplikace musí stejný záznam přidat do vyhledávací tabulky v produkční databázi.

V ideálním případě by nasazení databáze zahrnovalo zkopírování databáze z vývoje do produkčního prostředí. Mějte ale na paměti, že po nasazení aplikace a obnovení vývoje se produkční databáze naplní skutečnými daty od skutečných uživatelů. Pokud byste tedy při dalším nasazení jednoduše zkopírovali databázi z vývoje do produkčního prostředí, přepsali byste produkční databázi a ztratili by její stávající data. Výsledkem je, že nasazení databáze se omezuje na použití změn provedených ve vývojové databázi od posledního nasazení.

Vzhledem k tomu, že nasazení databáze zahrnuje použití změn ve schématu a případně dat od posledního nasazení, musí být historie změn zachována (nebo určena v době nasazení), aby bylo možné tyto změny použít v produkčním prostředí. Pro správu a použití změn datového modelu existuje celá řada technik.

Definování směrného plánu

Pokud chcete zachovat změny databáze aplikace, musíte mít nějaký počáteční stav, což je směrný plán, na který se změny použijí. V jednom extrémním počátečním stavu může být prázdná databáze bez tabulek, zobrazení nebo uložených procedur. Takový směrný plán má za následek velký protokol změn, protože musí zahrnovat vytvoření všech tabulek, zobrazení a uložených procedur databáze spolu se všemi změnami provedenými po počátečním nasazení. Na druhém konci spektra můžete nastavit směrný plán jako verzi databáze, která je původně nasazena do produkčního prostředí. Výsledkem této volby je mnohem menší protokol změn, protože zahrnuje pouze změny provedené v databázi po prvním nasazení. To je přístup, který dávám přednost. A samozřejmě můžete zvolit přístup, který je více uprostřed cesty, a definovat základní hodnoty jako určitý bod mezi počátečním vytvořením databáze a prvním nasazením databáze.

Jakmile zvolíte směrný plán, zvažte vygenerování skriptu SQL, který je možné spustit pro opětovné vytvoření základní verze. Takový skript umožňuje rychle znovu vytvořit základní verzi databáze. Tato funkce je obzvláště užitečná ve větších projektech, kde na projektu pracuje více vývojářů nebo v dalších prostředích, jako je testování nebo příprava, a každý z nich potřebuje vlastní kopii databáze.

Máte k dispozici celou řadu nástrojů pro generování skriptu SQL základní verze. V SQL Server Management Studio (SSMS) můžete kliknout pravým tlačítkem na databázi, přejít do podnabídky Úkoly a zvolit možnost Generovat skripty. Tím se spustí Průvodce skriptem, který vám dá pokyn k vygenerování souboru, který obsahuje příkazy SQL pro vytvoření objektů s databáze. Další možností je Průvodce publikováním databáze, který může vygenerovat příkazy SQL nejen pro vytvoření schématu databáze, ale také dat v databázových tabulkách. Průvodce publikováním databáze byl podrobně prozkoumán v kurzu Nasazení databáze . Bez ohledu na to, jaký nástroj použijete, byste nakonec měli mít soubor skriptu, který můžete použít k opětovnému vytvoření základní verze databáze, pokud to bude potřeba.

Dokumentace změn databáze v préce

Nejjednodušší způsob, jak během fáze vývoje udržovat protokol změn datového modelu, je zaznamenat změny v prázi. Pokud například během vývoje již nasazené aplikace přidáte do Employees tabulky nový sloupec, odeberete sloupec z Orders tabulky a přidáte novou tabulku (ProductCategories), zachováte textový soubor nebo dokument Microsoftu Word s následující historií:

Změnit datum	Změnit podrobnosti
2009-02-03:	Přidání sloupce DepartmentID (intNOT NULL) do Employees tabulky Přidání omezení cizího klíče z Departments.DepartmentID do Employees.DepartmentID.
2009-02-05:	Odebrání sloupce TotalWeight z Orders tabulky Data už jsou zachycená v přidružených OrderDetails záznamech.
2009-02-12:	Vytvořili jsme ProductCategories tabulku. Existují tři sloupce: (, , ), NOT NULLCategoryName (nvarchar(50), NOT NULL) a Active (bit, NOT NULL). IDENTITYintProductCategoryID Přidání omezení primárního klíče do ProductCategoryIDa výchozí hodnoty 1 do Active.

Tento přístup má řadu nevýhod. Pro začátek neexistuje žádná naděje na automatizaci. Kdykoli je potřeba tyto změny použít v databázi – například při nasazení aplikace – musí vývojář ručně implementovat každou změnu, jednu po druhé. Kromě toho, pokud potřebujete rekonstruovat konkrétní verzi databáze ze směrného plánu pomocí protokolu změn, bude to trvat déle a déle s tím, jak se zvětšuje velikost protokolu. Další nevýhodou této metody je, že srozumitelnost a úroveň podrobností každé položky protokolu změn je ponechána osobě, která změnu zaznamenává. V týmu s více vývojáři můžou někteří vytvářet podrobnější, čitelnější nebo přesnější záznamy než jiní. Jsou také možné překlepy a další chyby při zadávání dat související s člověkem.

Hlavní výhodou dokumentování změn databáze v prázi je jednoduchost. K vytváření a změnám databázových objektů nepotřebujete znalost syntaxe SQL. Místo toho můžete zaznamenat změny v prází a implementovat je prostřednictvím grafického uživatelského rozhraní SQL Server Management Studio s.

Udržování protokolu změn v prose není jistě příliš sofistikované a nebude dobře fungovat u určitých projektů, jako jsou projekty, které mají velký rozsah, mají časté změny datového modelu nebo zahrnují více vývojářů. Ale viděl jsem, že tento přístup funguje docela dobře v malých, jednočlenných projektech, které mají jen občas změny datového modelu a kde samostatný vývojář nemá silné zkušenosti se syntaxí SQL pro vytváření a změny databázových objektů.

Poznámka

I když jsou informace v protokolu změn technicky potřeba pouze do doby nasazení, doporučujeme uchovávat historii změn. Ale místo udržování jediného neustále se rozšiřujícího souboru protokolu změn zvažte použití jiného souboru protokolu změn pro každou verzi databáze. Obvykle budete chtít mít verzi databáze při každém nasazení. Díky údržbě protokolu změn můžete počínaje standardními hodnotami znovu vytvořit libovolnou verzi databáze spuštěním skriptů protokolu změn od verze 1 a pokračovat, dokud nedosáhnete verze, kterou potřebujete znovu vytvořit.

Záznam příkazů ZMĚN SQL

Hlavní nevýhodou údržby zápisu změn v prázi je nedostatečná automatizace. V ideálním případě by implementace změn databáze v produkční databázi v době nasazení byla stejně snadná jako kliknutí na tlačítko pro spuštění skriptu, a nemuselo by se ručně provádět seznam pokynů. Tato automatizace je možná udržováním protokolu změn, který obsahuje příkazy SQL používané ke změně datového modelu.

Syntaxe SQL obsahuje řadu příkazů pro vytváření a úpravy různých databázových objektů. Například příkaz CREATE TABLE při spuštění vytvoří novou tabulku se zadanými sloupci a omezeními. Příkaz ALTER TABLE upraví existující tabulku, přidá, odebere nebo upraví její sloupce nebo omezení. Existují také příkazy pro vytváření, úpravy a odstraňování indexů, zobrazení, uživatelem definovaných funkcí, uložených procedur, triggerů a dalších databázových objektů.

Když se vrátíme k našemu předchozímu příkladu, obrázek, který během vývoje již nasazené aplikace přidáte do Employees tabulky nový sloupec, odeberete z Orders tabulky sloupec a přidáte novou tabulku (ProductCategories). Výsledkem těchto akcí by byl soubor protokolu změn s následujícími příkazy SQL:

-- 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])
)

Odeslání těchto změn do produkční databáze v době nasazení je operace jedním kliknutím: otevřete SQL Server Management Studio, připojte se k produkční databázi, otevřete okno Nový dotaz, vložte obsah protokolu změn a kliknutím na Spustit spusťte skript.

Použití nástroje pro porovnání k synchronizaci datových modelů

Dokumentování změn databáze v prase je snadné, ale implementace změn vyžaduje, aby vývojář prováděl každou změnu v produkční databázi jeden po druhém; Dokumentování změn příkazů SQL umožňuje implementaci těchto změn v produkční databázi stejně snadno a rychle jako kliknutí na tlačítko, ale vyžaduje učení a zvládnutí příkazů a syntaxe SQL pro vytváření a změny databázových objektů. Nástroje pro porovnávání databází využijí z obou přístupů to nejlepší a zahodí ty nejhorší.

Nástroj pro porovnání databází porovná schéma nebo data dvou databází a zobrazí souhrnnou sestavu ukazující, jak se databáze liší. Kliknutím na tlačítko pak můžete vygenerovat příkazy SQL pro synchronizaci jednoho nebo více databázových objektů. Stručně řečeno, můžete použít nástroj pro porovnání databází k porovnání vývojových a produkčních databází v době nasazení a vygenerovat soubor, který obsahuje příkazy SQL, které po spuštění použije změny ve schématu produkční databáze tak, aby zrcadlil schéma vývojové databáze.

Existuje celá řada nástrojů pro porovnávání databází třetích stran, které nabízí mnoho různých dodavatelů. Jedním z takových příkladů je SQL Compare od Red Gate Software. Pojďme si projít procesem použití funkce SQL Compare k porovnání a synchronizaci schémat vývojových a produkčních databází.

Poznámka

V době psaní tohoto textu byla aktuální verze SQL Compare verze 7.1, přičemž edice Standard stála 395 USD. Postup můžete sledovat stažením bezplatné 14denní zkušební verze.

Při spuštění sql Compare se otevře dialogové okno Projekty porovnání, ve kterém se zobrazí uložené projekty SQL Compare. Vytvoření nového projektu Spustí se průvodce konfigurací projektu, který zobrazí výzvu k zadání informací o databázích k porovnání (viz obrázek 1). Zadejte informace o databázích vývojového a produkčního prostředí.

Obrázek 1: Porovnání vývojových a produkčních databází (kliknutím zobrazíte obrázek v plné velikosti)

Poznámka

Pokud je vaše databáze vývojového prostředí soubor databáze SQL Express Edition ve App_Data složce vašeho webu, budete ji muset zaregistrovat na SQL Server Express databázovém serveru, abyste ji mohli vybrat v dialogovém okně zobrazeném na obrázku 1. Nejjednodušším způsobem, jak toho dosáhnout, je otevřít SQL Server Management Studio (SSMS), připojit se k databázovému serveru SQL Server Express a připojit databázi. Pokud na počítači nemáte nainstalovanou aplikaci SSMS, můžete si stáhnout a nainstalovat bezplatnou SQL Server Management Studio.

Kromě výběru databází, které chcete porovnat, můžete také zadat různá nastavení porovnání na kartě Možnosti. Jednou z možností, kterou můžete chtít zapnout, je ignorovat názvy omezení a indexů. Připomeňme si, že v předchozím kurzu jsme do vývojových a produkčních databází přidali databázové objekty aplikačních služeb. Pokud jste pomocí aspnet_regsql.exe nástroje vytvořili tyto objekty v produkční databázi, zjistíte, že se názvy primárního klíče a jedinečných omezení mezi vývojovou a produkční databází liší. V důsledku toho sql Compare označí všechny tabulky aplikačních služeb jako odlišné. Můžete buď ponechat políčko Ignorovat názvy omezení a indexů nezaškrtnuté a synchronizovat názvy omezení, nebo můžete dát sqlu Compare pokyn, aby tyto rozdíly ignoroval.

Jakmile vyberete databáze, které chcete porovnat (a zkontrolujete možnosti porovnání), kliknutím na tlačítko Porovnat zahájíte porovnání. V následujících několika sekundách SQL Compare prozkoumá schémata obou databází a vygeneruje sestavu, jak se liší. Záměrně jsem provedl(a) nějaké změny vývojové databáze, aby bylo znázorněno, jak jsou tyto nesrovnalosti zaznamenány v rozhraní SQL Compare. Jak ukazuje obrázek 2, přidal BirthDate (a) jsem do Authors tabulky sloupec, odebral(a) ISBN jsem sloupec z Books tabulky a přidal(a) novou tabulku , která má uživatelům, kteří navštíví web, Ratingsumožnit hodnocení zkontrolovaných knih.

Poznámka

Změny datového modelu provedené v tomto kurzu byly provedeny pro ilustraci pomocí nástroje pro porovnání databází. Tyto změny v databázi nenajdete v budoucích kurzech.

Obrázek 2: Sql Compare Seznamy rozdíly mezi vývojovou a produkční databází (kliknutím zobrazíte obrázek v plné velikosti)

SQL Compare rozděluje databázové objekty do skupin, které rychle ukazují, jaké objekty existují v obou databázích, ale liší se, které objekty existují v jedné databázi, ale ne v druhé, a které objekty jsou identické. Jak vidíte, existují dva objekty, které existují v obou databázích, ale liší se: Authors tabulka s přidaným sloupcem a Books tabulka, která jeden odebrala. Existuje jeden objekt, který existuje pouze ve vývojové databázi, a to nově vytvořená Ratings tabulka. A v obou databázích je 117 objektů, které jsou identické.

Při výběru databázového objektu se zobrazí okno Rozdíly SQL, které ukazuje, jak se tyto objekty liší. Okno Rozdíly SQL zobrazené dole na obrázku 2 zvýrazňuje, že Authors tabulka ve vývojové databázi obsahuje BirthDate sloupec, který není v tabulce v Authors produkční databázi nalezen.

Po kontrole rozdílů a výběru objektů, které chcete synchronizovat, je dalším krokem vygenerování příkazů SQL potřebných k aktualizaci schématu produkční databáze tak, aby odpovídalo vývojové databázi. K tomu slouží Průvodce synchronizací. Průvodce synchronizací potvrdí, které objekty se mají synchronizovat, a shrnuje plán akcí (viz obrázek 3). Databáze můžete okamžitě synchronizovat nebo vygenerovat skript s příkazy SQL, které můžete spustit v klidu.

Obrázek 3: Synchronizace schémat databází pomocí Průvodce synchronizací (kliknutím zobrazíte obrázek v plné velikosti)

Nástroje pro porovnání databází, jako je red Gate Software s SQL Compare, umožňují použití změn ve schématu vývojové databáze v produkční databázi tak snadno, jako je point a kliknutí.

Poznámka

SQL Compare porovnává a synchronizuje dvě schémata databází. Bohužel nesrovnává a nesynchronizuje data v rámci dvou tabulek databází. Red Gate Software nabízí produkt s názvem SQL Data Compare , který porovnává a synchronizuje data mezi dvěma databázemi, ale je to samostatný produkt od SQL Compare a stojí dalších 395 USD.

Offline přecházení aplikace během nasazení

Jak jsme viděli v těchto kurzech, nasazení je proces, který zahrnuje několik kroků: kopírování ASP.NET stránek, stránek předlohy, souborů CSS, souborů JavaScriptu, obrázků a dalšího potřebného obsahu z vývojového prostředí do produkčního prostředí; kopírování konfiguračních informací specifických pro produkční prostředí, pokud je to potřeba; a použije změny datového modelu od posledního nasazení. V závislosti na počtu souborů a složitosti změn databáze může dokončení těchto kroků trvat od několika sekund až po několik minut. Během tohoto okna je webová aplikace v provozu a uživatelé, kteří navštíví web, může docházet k chybám nebo neočekávanému chování.

Při nasazování webu je nejlepší převést webovou aplikaci do režimu offline, dokud se nasazení nedokončilo. Převést aplikaci do offline režimu (a po dokončení procesu nasazení ji vrátit zpět) je stejně snadné jako nahrát soubor a pak ho odstranit. Počínaje ASP.NET 2.0, pouhá přítomnost souboru s názvem app_offline.htm v kořenovém adresáři aplikace přenese celý web "do offline režimu". Každý požadavek na ASP.NET stránku na tomto webu se automaticky odpoví obsahem app_offline.htm souboru. Po odebrání souboru se aplikace vrátí do režimu online.

Převést aplikaci během nasazení do offline režimu je pak stejně jednoduché jako nahrání app_offline.htm souboru do kořenového adresáře produkčního prostředí před zahájením procesu nasazení a jeho následné odstranění (nebo přejmenování na něco jiného) po dokončení nasazení. Další informace o této technice najdete v článku Johna Petersona Věnovaném ASP.NET aplikaci offline.

Souhrn

Hlavní výzva při nasazení aplikace řízené daty se zaměřuje na nasazení databáze. Vzhledem k tomu, že existují dvě verze databáze – jedna ve vývojovém prostředí a druhá v produkčním prostředí – můžou být tato dvě schémata databází po přidání nových funkcí do vývoje nesynchronní. A co víc, protože produkční databáze je naplněná skutečnými daty od skutečných uživatelů, nemůžete přepsat produkční databázi upravenou vývojovou databází tak, jak je to možné při nasazování souborů, které tvoří aplikaci (stránky ASP.NET, soubory obrázků atd.). Nasazení databáze místo toho zahrnuje implementaci přesné sady změn provedených ve vývojové databázi v produkční databázi od posledního nasazení.

Tento kurz se zabýval třemi technikami pro správu a použití protokolu změn databáze. Nejjednodušším způsobem je zaznamenat změny v prách. I když tato taktika dělá z implementace těchto změn v produkční databázi ruční proces, nevyžaduje znalost příkazů SQL pro vytváření a změny databázových objektů. Sofistikovanější přístup, který je mnohem přijatelnější ve větších projektech nebo projektech s více vývojáři, je zaznamenat změny jako řadu příkazů SQL. To výrazně zrychlová zavádění těchto změn v cílové databázi. Nejlepšího z obou přístupů lze dosáhnout pomocí nástroje pro porovnávání databází, jako je například Porovnání sql aplikací Red Gate Software.

Tento kurz uzavírá naše zaměření na nasazení aplikace řízené daty. V další sadě kurzů se dozvíte, jak reagovat na chyby v produkčním prostředí. Podíváme se na to, jak místo žluté obrazovky smrti zobrazit popisnou chybovou stránku. A podíváme se, jak protokolovat podrobnosti o chybě a jak vás na takové chyby upozornit.

Šťastné programování!

PředchozíDalší