Implementarea bazelor de date SQL Server de la Test la Live

Folosesc mecanismul de migrație al lui Subsonic, așa că am doar un dll cu clase în ordine squientă care au 2 metode, în sus și în jos. Există un cârlig de integrare / construire continuă în nant, astfel încât să pot automatiza actualizarea bazei de date.

Nu este cel mai bun tigru din lume, dar bate scris DDL.

Ca Rob Allen, folosesc SQL Compare / Data Compare de Redgate. De asemenea, utilizez expertul de publicare de baze de date de la Microsoft. De asemenea, am o aplicație de consolă pe care am scris-o în C# care ia un script SQL și o execută pe un server. În acest fel, puteți rula scripturi mari cu comenzi "GO" din ea dintr-o linie de comandă sau într-un script batch.

Folosesc bibliotecile Microsoft.SqlServer.BatchParser.dll și Microsoft.SqlServer.ConnectionInfo.dll din aplicația consola.

Dacă aveți o companie care o cumpără, Toad de la Quest Software are acest tip de funcționalitate de management construit. Este practic o operație cu două clicuri pentru a compara două scheme și a genera un script de sincronizare de la unul la celălalt.

Ele au ediții pentru majoritatea bazelor de date populare, inclusiv, desigur, serverul Sql.

Lucrez la fel ca și Karl, păstrând toate scripturile mele SQL pentru crearea și modificarea tabelelor într-un fișier text pe care îl păstrez în controlul sursei. De fapt, pentru a evita problema de a avea un script să examineze baza de date live pentru a determina ce trebuie să ruleze ALTER, de obicei, lucrez astfel:

• În prima versiune, plasez totul în timpul testării într-un singur script SQL și tratez toate tabelele ca CREATE. Aceasta inseamna ca in timpul testelor incheg sa cada si sa citesc tabele foarte mult, dar asta nu e prea mare pentru inceputul proiectului (de obicei intrucat folosesc datele pe care le folosesc la acel moment).
• În toate versiunile ulterioare, fac două lucruri: fac un nou fișier text pentru a ține scripturile SQL de actualizare, care conțin doar ALTER-urile pentru acea versiune. Și fac modificările la original, crează și un script de bază de date proaspăt. În acest fel, un upgrade rulează doar scriptul de actualizare, dar dacă trebuie să recreăm DB, nu este nevoie să rulați 100 de scripturi pentru a ajunge acolo.
• În funcție de modul în care implementez modificările bazei de date, de obicei, o să pun și o tabelă de versiuni în DB care conține versiunea DB. Apoi, mai degrabă decât să luăm decizii umane cu privire la care script-uri să fie difuzate, indiferent de codul pe care l-am rulat, scripturile de creare / upgrade utilizează versiunea pentru a determina ce să ruleze.

Singurul lucru pe care acest lucru nu-l va face este să vă ajute dacă o parte din ceea ce vă deplasați de la test la producție este date, dar dacă doriți să gestionați structura și să nu plătiți pentru un pachet frumos, dar costisitor de gestionare a DB-ului, într-adevăr nu este foarte dificil. De asemenea, am descoperit că este o modalitate destul de bună de a ține evidența mentală a DB-ului tău.

For my projects I alternate between SQL Compare from REd Gate and the Database Publishing Wizard from Microsoft which you can download free here.

Expertul nu este la fel de slick ca SQL Compare sau SQL Data Compare, dar face truc. O problemă este că scripturile pe care le generează pot avea nevoie de o rearanjare și / sau de editare pentru a curge într-o singură fotografie.

Pe partea superioară, aceasta poate muta schema și datele dvs., ceea ce nu este rău pentru un instrument gratuit.

Utilizând SMO / DMO, nu este prea dificil să generați un script al schemei. Datele sunt puțin mai distractive, dar totuși posibile.

În general, eu iau abordarea "Script It", dar ați putea dori să luați în considerare ceva în acest sens:

• Distingeți între dezvoltare și stadializare, astfel încât să puteți dezvolta cu un subset de date ... aceasta aș crea un instrument care să scadă pur și simplu unele date de producție sau să genereze date false în ceea ce privește securitatea.
• Pentru dezvoltarea echipei, fiecare schimbare în baza de date trebuie să fie coordonată între membrii echipei. Modificările schemelor și datelor pot fi intercalate, însă un singur script ar trebui să permită o caracteristică dată. Odată ce toate funcțiile dvs. sunt gata, le legați într-un singur fișier SQL și executați acest lucru împotriva unei restaurări a producției.
• Odată ce stadializarea ți-a anulat acceptarea, executați din nou singurul fișier SQL pe mașina de producție.

Am folosit instrumentele Red Gate și sunt instrumente minunate , dar dacă nu vă puteți permite, construirea instrumentelor și lucrul în acest fel nu este prea departe de ideal.

Sunt de acord că scrierea totul este cel mai bun mod de a merge și este ceea ce susțin la locul de muncă. Ar trebui să scrii totul de la DB și crearea de obiecte la popularea tabelelor de căutare.

Orice veți face în UI nu va fi tradus (mai ales pentru schimbări ... nu atât pentru primele implementări), și va termina necesitatea unor instrumente cum ar fi ceea ce oferă Redgate.

M-am codificat manual toate instrucțiunile DDL (creează / alter / șterge), adăugându-le în .sln ca fișiere text și folosind versiuni normale (folosind subversiune, dar ar trebui să funcționeze orice control de revizie). În acest fel, nu numai că am avantajul versiunii, dar actualizarea în direct din dev / stage este același proces pentru cod și bază de date - etichete, sucursale și așa mai departe.

În caz contrar, sunt de acord că Redgate este costisitoare dacă nu aveți o companie care să o cumpere pentru dvs. Dacă puteți obține o companie să-l cumpere pentru tine, deși, într-adevăr merită!

Sunt de acord să păstrez totul în controlul sursei și să scriu manual toate modificările. Modificările aduse schemei pentru o singură versiune merg într-un fișier de script creat special pentru lansarea respectivă. Toate procs stocate, vizualizări etc ar trebui să meargă în fișiere individuale și tratate la fel ca .cs sau .aspx în măsura în care controlul sursei merge. Eu folosesc un script de powershell pentru a genera un fișier .sql mare pentru actualizarea chestii de programabilitate.

Nu-mi place automatizarea aplicării modificărilor schemelor, cum ar fi tabele noi, coloane noi etc. Când facem o versiune de producție, îmi place să trec prin comanda script-ului de schimbare prin comandă pentru a vă asigura că fiecare lucrează așa cum era de așteptat. Nu este nimic mai rău decât să rulați un scenariu de mare schimbare în producție și să obțineți erori pentru că ați uitat niște detalii care nu s-au prezentat în curs de dezvoltare.

Am aflat, de asemenea, că indicele trebuie tratat la fel ca fișierele de cod și pus în controlul sursei.

Și ar trebui să aveți cu siguranță mai mult de două baze de date - dev și live. Ar trebui să aveți o bază de date dev pe care toată lumea o folosește pentru sarcini zilnice dev. Apoi, o bază de date staging care imită producția și este folosită pentru a vă face testarea integrării. Apoi, poate o copie completă recentă a producției (restaurată dintr-o copie de rezervă completă), dacă acest lucru este fezabil, astfel încât ultima rundă de testare a instalării să se potrivească cu ceva care este cât se poate de apropiat de cel real.

RedGate SqlCompare is a way to go in my opinion. We do DB deployment on a regular basis and since I started using that tool I have never looked back. Very intuitive interface and saves a lot of time in the end.

Versiunea Pro va avea grijă și de scripting-ul pentru integrarea controlului sursă.

Fac toată crearea bazei de date ca DDL și apoi împachetez DDL-ul într-o clasă de întreținere a schemei. Eu pot face diferite lucruri pentru a crea DDL în primul rând, dar în mod fundamental fac toate maint schema în cod. Acest lucru înseamnă, de asemenea, că, dacă aveți nevoie să faceți lucruri non DDL care nu se potrivesc bine cu SQL, puteți scrie logică procedurală și o puteți rula între bucăți de DDL / DML.

DBS-ul meu are apoi un tabel care definește versiunea curentă, astfel încât se poate codifica un set relativ simplu de teste:

1. Există DB? Dacă nu îl creați.
2. DB este versiunea curentă? Dacă nu, atunci executați metodele, în ordine, care aduc schema la zi (poate doriți să solicitați utilizatorului să confirme și - în mod ideal - să facă copii de rezervă în acest moment).

Pentru o aplicație cu un singur utilizator, rulați acest lucru în loc, pentru o aplicație web pe care o blocăm în prezent, dacă versiunile nu se potrivesc și dacă avem o aplicație independentă pentru schema de întreținere pe care o executăm. Pentru multi-utilizatori va depinde de mediul particular.

Avantajul? Ei bine, am un nivel foarte înalt de încredere că schema pentru aplicațiile care utilizează această metodologie este consecventă în toate cazurile acestor aplicații. Nu este perfect, există probleme, dar funcționează ...

Există unele probleme atunci când se dezvoltă într-un mediu de echipă, dar asta este mai mult sau mai puțin o dat oricum!

Murph

Nu uitați soluția Microsoft la această problemă: Visual Studio 2008 Database Edition . Include instrumente pentru implementarea modificărilor la baze de date, producerea unei diffeciuni între bazele de date pentru modificarea schemelor și / sau a datelor, teste unitare, generarea de date de testare.

Este destul de scump dar am folosit ediția de probă pentru o vreme și am crezut că este strălucită. Face baza de date la fel de ușor de folosit ca orice altă bucată de cod.

I'm currently working the same thing to you. Not only deploying SQL Server databases from test to live but also include the whole process from Local -> Integration -> Test -> Production. So what can make me easily everyday is I do NAnt task with Red-Gate SQL Compare. I'm not working for RedGate but I have to say it is good choice.

De asemenea, păstrez scripturi pentru toate obiectele și datele mele. Pentru implementare am scris acest utilitar gratuit - http://www.sqldart.com . Acesta vă va permite să reordonați fișierele de script și veți rula întregul lot în cadrul unei tranzacții.