Menținerea sincronizării bazei de date WordPress între mai mulți dezvoltatori folosind Git

20 mai 2012, 21:20:21
Vizualizări: 17.2K
Voturi: 38

Lucrez la îmbunătățirea fluxului de lucru cu Git în proiectele mele de dezvoltare WordPress. Adesea, când dezvolt un sistem de management al conținutului, creez un server de dezvoltare (de exemplu http://dev.finalsitename.com) care conține tipurile de postări personalizate și taxonomiile care vor fi utilizate în versiunea de producție. Acest lucru permite clientului meu să înceapă să adauge conținut pe site.

În timp ce ei lucrează la această sarcină, eu de obicei construiesc aspectul și funcționalitățile personalizate/plugin-uri care vor fi utilizate în mediul meu localhost. Pentru a mă asigura că nu suprascriu actualizările lor, de obicei descarc o copie a bazei lor de date și o înlocuiesc pe a mea. Totuși, sunt cazuri când trebuie să intru rapid în panoul de administrare WordPress pentru a modifica o setare sau altceva minor...

Când mai mulți dezvoltatori lucrează la un proiect WordPress, fiecare face un dump (cu marcaj de timp) al versiunii sale a bazei de date și îl include în directorul root înainte de commit și push către repository-ul remote. Problema cu această abordare este că bazele de date sunt adesea desincronizate, fără o modalitate ușoară de a determina care versiune să fie utilizată.

Ce alte metode folosesc alți dezvoltatori pentru a menține bazele de date sincronizate, permițând în același timp mai multor dezvoltatori (și clienți/producători de conținut) să lucreze la același proiect?

0
Toate răspunsurile la întrebare 4
0
13

Există 3 opțiuni, de la cea mai ușoară -->

  1. Utilizați o singură bază de date la distanță la care vă conectați toți, cu multe backup-uri. În acest fel, trebuie să vă preocupați doar de fișiere și nu de baza de date.

  2. Utilizați funcționalitatea de import și export integrată în WordPress și încărcați-o în sistemul de control al versiunilor direct în directorul root al WordPress (de exemplu, într-un folder nou). Desigur, durează câteva minute în plus, dar este extrem de simplu și îl puteți automatiza, iar mai important, va face parte din controlul versiunilor.

  3. Utilizați un script personalizat de actualizare pentru a sincroniza versiunile bazei de date. Sincer, nu știu cum puteți gestiona asta cu git, deoarece este doar un script și nu înțelege cu adevărat ce se întâmplă, dar știu că există instrumente externe care fac acest lucru, atât comerciale cât și gratuite ( http://www.liquibase.org/).

21 mai 2012 02:02:11
1

Dacă aveți nevoie să mențineți bazele de date sincronizate în totalitate, adică atât schema cât și datele, ați putea dezvolta un sistem personalizat de versionare bazat pe backup-uri.

Sau dacă doriți să păstrați datele de la producție dar să evoluați schema, ați putea lucra cu o soluție personalizată (un fișier versionat cu toate modificările de schemă), sau cu o soluție standard bazată pe conceptul de migration. Puteți găsi mai multe informații în acest thread stackoverflow: Mecanisme pentru urmărirea modificărilor de schemă în baze de date.

20 mai 2012 22:37:59
0

Îmi cer scuze dacă acest lucru pare incredibil de evident, dar dacă toți aveți nevoie de aceeași copie a bazei de date cu aceeași structură, nu ar fi mai logic să aveți un server SQL central/oficial și să îl utilizați? Puteți clona local dacă aveți nevoie să experimentați, dar păstrați-l ca standard autoritativ de facto și faceți backup-uri doar pentru acel server.

În caz contrar, când lucrez la un proiect de grup, fiecare are propria configurație cu conținut diferit. Codul se ocupă de actualizarea și migrarea structurilor de tabele și putem accesa instalările locale ale codului care rulează pe mașinile noastre prin LAN, deci nu este nevoie să partajăm conținutul.

Dacă introducem conținut, îl rulăm pe un server de testare pe care îl putem exporta și importa în serverul live sau putem migra direct pe serverul de producție dacă nu există deja o instanță live.

Dacă la un moment dat aveți nevoie de separarea între date live, de testare și cele în curs de dezvoltare, atunci folosiți ramuri (branches) separate în repository-ul vostru: live, test și development.

20 mai 2012 23:47:05
2

Pentru cei care nu consideră că soluțiile de mai sus sunt suficient de ușoare, o excelentă soluție prin intermediul unui plugin premium este WP Migrate DB Pro.

Acesta vă permite să transmiteți și să preluați baze de date între instanțe WordPress. Încă nu oferă un sistem asemănător cu Git pentru bazele de date, dar dacă aveți un server de staging central care reprezintă "adevărul" pentru bazele de date și unde ar trebui să se facă modificări, funcționează minunat.

(Sugestie învechită mai jos - Mulțumiri lui Elmar în comentarii)

Sau ați putea investiga Version Press, care pretinde că oferă o gestionare asemănătoare cu Git pentru fișiere și baze de date. Nu am folosit acest plugin, însă l-am urmărit de ceva timp și încă există, deci...

14 apr. 2021 06:34:56
Comentarii

Din păcate, Version Press nu mai este dezvoltat activ...

Elmar Zander Elmar Zander
1 sept. 2021 18:31:41

Mulțumesc @ElmarZander, mi-am actualizat răspunsul.

Jake Jake
2 sept. 2021 06:46:29