Vreau sa va intreb cum folositi version control pentru website-uri complete (nu pentru dezvoltare de plugin-uri sau teme individuale / generale) si ce fisiere includeti in aceasta? Cand zic website, ma refer in general la o tema personalizata, dedicata unui singur client si un mix de plugin-uri gratis si cumparate.
Pe durata de viata a unui astfel de proiect am nevoie de 3 instante de WordPress: dev, staging si live. In general, instanta de staging poate fi copie identica a instantei de dev, doar ca pe un server public (nu vreau sa adaug acelasi content de 2 ori). Atat dev-ul cat si staging-ul sunt ciorne ce cuprind doar date de test, scenarii uzuale si edge cases, diferite de cele din productie (unde mai intervin si alte prioritati precum security, caching, privacy).
Pentru version control, includ intreaga instanta WordPress de dev, cu tot cu dump-ul SQL (exceptand evident wp-config). Ca avantaje, asta imi permite mie, colegilor sau clientului (subcontractor, deh) sa aibe o solutie functionala instant. Fisierele core si dump devin practic un mediu de test pentru solutia aleasa. Ca dezavantaje, 2 persoane nu (cred ca) pot lucra concomitent pe modificari de content (m-am ferit din instinct de merge-uit dump-ul, poate fara un motiv bun) si sunt multe fisiere stocate in VC.
Pentru sincronizarea cu staging, am un php script ce face o copie fidela prin ssh, rsync si wp-cli (nu as vrea neaparat sa leg un git push de publicarea pe staging, ci sa decid eu cand fac acest sync), in ambele sensuri (pull sau push).
Pentru sincronizarea cu serverul live, scriptul de mai sus copiaza doar fisierele temei si plugin-urilor dedicate proiectului.
Pentru aplicatii web, imi este clar workflow-ul VCS (ai composer, ai migrations & fixtures, ai unit & functional tests). La fel si pentru plugin-uri / teme generaliste.
Intrebarea mea se referea strict la solutia completa, compusa de obicei din fisiere + DB, unde una dintre tinte este si automatizarea si eliminarea pe cat posibil a muncii de configurare si introducere si duplicare a datelor.
Eu unul folosesc bedrock, ce presupune wp core ca dependinta a proiectului, la fel si tema (eu o prefer ca submodul git, dar nu e musai) sau pluginurile, totul cu composer la baza.
Configurarile (pt conectare la db si altele) se fac prin dotenv si sunt specifice instantei (dev, stage, live) deci nu apar sub git, doar template-ul lor e sub git. In acelasi repo e si un vagrant box cu configurarile serverului live (php version, sql version, site path, etc.) pt instanta de dev locala.
Pt mutare (stage -> live sau alte variante) un bash script mic impacheteaza db (exportat prin wp-cli) si uploads pt mutare. Box-ul e configurat sa importe la vagrant up baza de date daca exista intr-un folder al proiectului.
Ideea din spatee bedrock e ca definesti URL-ul sitului in fisierul de configuare, deci nu te intereseaza ce a trecut wp-ul in db, merge mutata baza de date dintr-o parte in alta fara probleme, fara search-replace si alte nebunii. Bonus: Soil mai corecteaza niste legaturi absolute generate de wp.
Practic scriptul de deploy pe live are la baza: git pull && composer update cu update de uploads si db daca pui continutul pe stage mai intai. Bedrock ar prefera trellis sau capistrano pt deploy, dar cum sunt bazate pe ansible, nu merg bine cu Windows si le-am evitat.
