Cum gestionați bazele de date în dezvoltare, testare și producție?

Am încercat cu greu să găsesc exemple bune de gestionare a schemelor și datelor bazelor de date între serverele de dezvoltare, testare și producție.

Iată configurația noastră. Fiecare dezvoltator are o mașină virtuală care rulează aplicația noastră și baza de date MySQL. Nisipul lor personal este să facă tot ce vor. În prezent, dezvoltatorii vor face o schimbare în schema SQL și vor efectua o descărcare a bazei de date într-un fișier text pe care îl angajează în SVN.

Vrem să implementăm un server de dezvoltare continuă pentru integrare, care va executa întotdeauna cel mai recent cod angajat. Dacă facem asta acum, va reîncărca baza de date de la SVN pentru fiecare construcție.

Avem un server de testare (virtual) care rulează "candidați de lansare". Implementarea pe serverul de testare este în prezent un proces foarte manual și, de obicei, implică încărcarea ultimului SQL din SVN și alinierea lui. De asemenea, datele de pe serverul de testare sunt incoerente. Încheiați cu toate datele de testare pe care le avea ultimul dezvoltator pe serverul său de nisip.

În cazul în care totul se descompune este desfășurarea la producție. Deoarece nu putem suprascrie datele live cu date de testare, acest lucru implică re-crearea tuturor modificărilor schemelor. Dacă au existat numeroase modificări de schemă sau scripturi de conversie pentru a manipula datele, acest lucru poate deveni cu adevărat păros.

Dacă problema ar fi doar schema, ar fi o problemă mai ușoară, dar există date "de bază" în baza de date care este actualizată și în timpul dezvoltării, cum ar fi metadatele în tabelele de securitate și permisiuni.

Aceasta este cea mai mare barieră pe care o văd în trecerea la o integrare continuă și la un pas. Cum rezolvați tu ?


O întrebare de urmărire: cum urmăriți versiunile bazei de date, astfel încât să știți care sunt scripturile de rulare pentru a face upgrade la o instanță dată de bază de date? Este o tabelă de versiuni, cum ar fi Lance, menționată sub procedura standard?


Thanks for the reference to Tarantino. I'm not in a .NET environment, but I found their DataBaseChangeMangement wiki page to be very helpful. Especially this Powerpoint Presentation (.ppt)

Voi scrie un script Python care verifică numele de script-uri *. Sql într-un director dat într-un tabel din baza de date și le execută pe cele care nu sunt în ordine pe baza unui număr întreg care formează prima parte a fișierului. Dacă este o soluție destul de simplă, după cum bănuiesc că va fi, atunci o voi posta aici.


Am un script de lucru pentru asta. Acesta se ocupă de inițializarea DB dacă nu există și execută scripturile de upgrade după cum este necesar. Există, de asemenea, comutatoare pentru ștergerea unei baze de date existente și importul datelor de test dintr-un fișier. Sunt aproximativ 200 de linii, deci nu voi posta (deși aș putea să pun pastebin dacă există interes).

0
fr hi bn
Relevant: Cel mai bun instrument pentru sincronizarea bazelor de date MySQL »> stackoverflow.com/questions/52583/ & hellip;
adăugat autor Ashwin A, sursa

14 răspunsuri

Există câteva opțiuni bune. Nu aș folosi strategia "restaura o copie de rezervă".

  1. Scrieți toate modificările schimbei și serverul dvs. CI trebuie să ruleze acele scripturi din baza de date. Aveți un tabel de versiuni pentru a urmări versiunea curentă a bazei de date și executați script-urile doar dacă sunt pentru o versiune mai nouă.

  2. Utilizați o soluție de migrare. Aceste soluții variază în funcție de limbă, dar pentru .NET folosesc Migrator.NET. Acest lucru vă permite să faceți o versiune a bazei de date și să vă deplasați în sus și în jos între versiuni. Schema dvs. este specificată în codul C #.

0
adăugat

Pentru baza de date Oracle folosim instrumentele oracle-ddl2svn .

Acest proces automatizat procesul următor

  1. pentru fiecare schemă db obțineți scheme ddls
  2. puneți-l sub versiunea contol

schimbările între instanțe rezolvate manual

0
adăugat

Am scris un instrument care (prin accesarea Open DBDiff ) compară schemele bazei de date și va sugera migrarea scripturi pentru tine. Dacă efectuați o modificare care șterge sau modifică date, aceasta va arunca o eroare, dar va oferi o sugestie pentru script (de exemplu, când o coloană lipsește în noua schemă, va verifica dacă coloana a fost redenumită și a crea xx - a generat script.sql.suggestion care conține o instrucțiune de redenumire).

http://code.google.com/p/migrationscriptgenerator/ SQL Server only I'm afraid :( It's also pretty alpha, but it is VERY low friction (particularly if you combine it with Tarantino or http://code.google.com/p/simplescriptrunner/)

Modul în care o folosesc este să aveți un proiect de script-uri SQL în .sln. Aveți, de asemenea, o bază de date db_next locală la care faceți modificările dvs. (utilizând Management Studio sau NHibernate Schema de export sau LinqToSql CreateDatabase sau ceva similar). Apoi executați migrationscriptgenerator cu DB-urile _dev și _next, care creează. script-urile de actualizare SQL pentru migrarea între ele.

0
adăugat

Mă tem că sunt de acord cu alte postere. Dezvoltatorii trebuie să scrii schimbările lor.

În multe cazuri un simplu ALTER TABLE nu va funcționa, trebuie să modificați și datele existente - dezvoltatorii trebuie să se gândească la ce migrații sunt necesare și să se asigure că sunt scripturi corecte (bineînțeles că trebuie să testați acest lucru cu atenție la un moment dat în ciclul de eliberare).

Mai mult, dacă aveți vreun sens, îi veți face pe dezvoltatori să revină la scripturi pentru modificările lor, astfel încât aceștia să poată fi reluați dacă este cazul. Acest lucru ar trebui să fie testat, de asemenea, pentru a se asigura că răsturnarea nu se execută numai fără eroare, ci lasă DB în aceeași stare ca și în trecut (acest lucru nu este întotdeauna posibil sau de dorit, dar este o regulă bună de cele mai multe ori) .

Cum îl prindem într-un server CI, nu știu. Poate că serverul dvs. CI trebuie să aibă un instantaneu de construcție cunoscut, pe care îl revine în fiecare noapte și apoi aplică toate schimbările de atunci. Probabil că este mai bine, altfel un script de migrare rupt va sparge nu doar construcția acelei nopți, ci toate celelalte.

0
adăugat

Avem o configurație foarte asemănătoare cu OP.

Dezvoltatorii se dezvoltă în VM cu DB-uri private.

[Dezvoltatorii vor fi în curând angajați în filiale private]

Testarea se execută pe diferite mașini (de fapt, în VM-urile găzduite pe un server) [În curând va fi condus de serverul Hudson CI]

Testați prin încărcarea dumpului de referință în db. Aplicați patch-urile pentru schemele dezvoltatorilor apoi aplicați patch-urile pentru dezvoltatori

Apoi efectuați testele de unitate și sistem.

Producția este distribuită clienților în calitate de instalatori.

Ce facem:

Luăm o schemă de depozitare a DB-ului nostru de nisip. Apoi o ștergere de date sql. Diferență față de linia de bază anterioară. acea pereche de delte este să faceți upgrade n-1 la n.

configuram gropile și deltele.

Deci, pentru a instala versiunea N CLEAN, rulați dump-ul într-un db gol. Pentru a patch-uri, aplicați patch-urile intervenitoare.

(Juha a menționat ideea lui Rail de a avea un tabel care să înregistreze actuala versiune DB este una bună și ar trebui să facă instalarea actualizărilor mai puțin plină.)

Deltasurile și haldele trebuie revizuite înainte de testul beta. Nu văd nimic în jurul valorii de acest lucru, așa cum am văzut dezvoltatorii inserați conturi de testare în DB pentru ei înșiși.

0
adăugat

Dacă vă aflați în mediul .NET, soluția este Tarantino . Se ocupă de toate acestea (inclusiv ce script-uri sql să se instaleze) într-o construcție NANT.

0
adăugat
adăugat autor Lee Richardson, sursa

The book Refactoring Databases: Evolutionary Database Design might give you some ideas on how to manage the database. A short version is readable also at http://martinfowler.com/articles/evodb.html

Într-un singur proiect PHP + MySQL am avut numărul de revizie a bazei de date stocate în baza de date și când programul se conectează la baza de date, va verifica mai întâi revizia. Dacă programul necesită o revizuire diferită, va deschide o pagină pentru actualizarea bazei de date. Fiecare actualizare este specificată în cod PHP, care va schimba schema bazei de date și va migra toate datele existente.

0
adăugat

Aruncați o privire asupra modului în care ruby on Rails face acest lucru.

Mai întâi, există așa-numitele fișiere de migrare, care transformă în principiu schema bazei de date și datele de la versiunea N la versiunea N + 1 (sau în caz de retrogradare de la versiunea N + 1 la N). Baza de date are o tabelă care spune versiunea curentă.

Bazele de date de testare sunt șterse întotdeauna înainte de testele de unitate și sunt populate cu date fixe din fișiere.

0
adăugat

De asemenea, puteți să vă uitați la utilizarea unui instrument precum Comparați SQL pentru a scrie scriptul diferența între diferitele versiuni ale unei baze de date, permițându-vă să migrați rapid între versiuni

0
adăugat
  • Denumiți-vă bazele de date după cum urmează - db_dev, db_test, db_qa, db_prod (Evident, nu trebuie să aveți niciodată nume hardcod db
  • Astfel veți putea implementa chiar și tipul diferit de db pe același server fizic (nu recomand acest lucru, dar este posibil să ... dacă resursele sunt strânse)
  • Asigurați-vă că veți putea să mutați date între cele automat
  • Separați scripturile de creare a db-urilor de la populație = Ar trebui să fie întotdeauna posibilă recrearea db-ului de la zero și umflarea lui (din vechea versiune db sau din sursa externă de date
  • nu folosiți șiruri de conexiune hardcode în cod (chiar și în fișierele config) - utilizați în șabloanele de șir de conexiuni pentru fișierele config, pe care le ocupați dinamic, fiecare reconfigurare a aplicației_layer care are nevoie de recompilare este BAD
  • utilizați versiunile de baze de date și versiunile de obiecte db - dacă vă puteți permite să utilizați produse gata, dacă nu dezvoltați ceva pe cont propriu
  • urmăriți fiecare schimbare DDL și salvați-o într-o anumită tabelă de istoric ( exemplu aici )
  • Backups de zi cu zi! Testați cât de repede ați putea restaura ceva pierdut dintr-o copie de siguranță (utilizați scripturi automate de restaurare
  • )
  • chiar si baza de date DEV si PROD au exact acelasi script de creatie veti avea probleme cu datele, asa ca permiteti dezvoltatorilor sa creeze copia exacta a prod si sa se joace cu ea (stiu ca voi primi minusuri pentru aceasta, dar schimbarea mentalității și a procesului de afaceri vă va costa mult mai puțin atunci când rahatul atinge ventilatorul - forțați astfel codificatorii să indice legale ceea ce face, dar asigurați-vă acest lucru
0
adăugat

Dezvoltatorii dvs. trebuie să scrie scripturi de schimbare (schiță și schimbare de date) pentru fiecare problemă / funcție de care lucrează, nu doar să arunce întreaga bază de date în controlul sursei. Aceste scripturi vor actualiza baza de date curentă de producție la noua versiune în curs de dezvoltare.

Procesul dvs. de construire poate restaura o copie a bazei de date de producție într-un mediu adecvat și poate rula toate scripturile de la sursa de control pe ea, care va actualiza baza de date la versiunea curentă. Facem acest lucru zilnic pentru a ne asigura că toate scripturile rulează corect.

0
adăugat

Folosim linia de comandă mysql-diff : se emite o diferență între două scheme de baze de date ( din live DB sau script) ca script ALTER. mysql-diff este executat la începutul aplicației, iar dacă schema se modifică, raportează dezvoltatorului. Deci, dezvoltatorii nu au nevoie să scrie manual ALTER, actualizările schemelor se întâmplă semi-automat.

0
adăugat

Acesta este un lucru pe care sunt în mod constant nesatisfăcut - soluția noastră la această problemă care este. De câțiva ani am păstrat un script separat de schimbare pentru fiecare versiune. Acest script ar conține deltele de la ultima versiune de producție. Cu fiecare lansare a aplicației, numărul versiunii va crește, dând ceva de genul:

  • dbChanges_1.sql
  • dbChanges_2.sql
  • ...
  • dbChanges_n.sql

Acest lucru a funcționat suficient de bine până am început să menținem două linii de dezvoltare: Trunk / Mainline pentru o nouă dezvoltare și o ramură de întreținere pentru remedierile de erori, îmbunătățiri pe termen scurt etc. Nevoia a fost necesară pentru a schimba schema din ramură. În acest moment, am avut deja dbChanges_n + 1.sql în Trunk, așa că am ajuns să mergem cu o schemă cum ar fi:

  • dbChanges_n.1.sql
  • dbChanges_n.2.sql
  • ...
  • dbChanges_n.3.sql

Din nou, acest lucru a funcționat destul de bine, până când într-o zi ne-am uitat în sus și am văzut 42 de scripturi delta în linia principală și 10 în ramură. Argh!

Aceste zile pur și simplu menținem un script delta și lăsăm versiunea SVN - adică suprascriem scenariul cu fiecare versiune. Și ne-am împiedicat să facem schimbări de schemă în ramuri.

Deci, nici eu nu sunt mulțumit de asta. Îmi place foarte mult conceptul de migrație de la Rails. Am devenit destul de fascinat de LiquiBase . Acesta susține conceptul de refactorizări de baze de date incrementale. Merită o privire și mă voi uita în detaliu în curând. Oricine are experiență cu asta? Aș fi foarte curios să aud despre rezultatele dvs.

0
adăugat

Verificați dbdeploy , există deja instrumente Java și .net, puteți urma standardele lor pentru machetele de fișiere SQL și tabelul versiunii schemei și scrieți versiunea python.

0
adăugat
MySQL - comunitatea Română
MySQL - comunitatea Română
19 participanți

Comunitatea română a programatorilor MySQL.