Dezvoltare, Staging și Implementare în Producție pentru Site-uri WordPress

Am o configurație de care sunt destul de mândru și care funcționează extrem de bine pentru echipa mea.

Structura generală

Țin întreaga instalație sub controlul git. Toate modificările, fie că e vorba de o actualizare de sistem, adăugarea/actualizarea unui plugin, adăugarea/actualizarea unei teme, trec prin același flux de lucru. Modificările pot fi anulate în câteva clipe. Am un server de deploy (un vechi desktop P4) care rulează gitosis, dar la fel de bine ați putea folosi github sau gitolite. În git, am două ramuri "speciale", master și develop (explicate mai jos). Serverele mele de producție și staging sunt bazate pe cloud.

Medii de dezvoltare

Fiecare dezvoltator își rulează propriul server de dezvoltare pe mașina personală. În ceea ce privește bazele de date, nevoia de date live nu a fost aproape niciodată o problemă. Folosim în principal datele de test pentru teme. Altfel, exportul și importul acoperă majoritatea nevoilor. Dacă partea de baze de date ar fi crucială, ați putea configura replicarea sau ceva pentru sincronizare la cerere. Când am configurat inițial această structură, am crezut că acest lucru va fi crucial, așa că am început să scriu un set de unelte pentru asta, dar spre surpriza mea, nu au fost necesare. (notă: deoarece nu au fost necesare, nu le-am perfecționat niciodată, așa că există bug-uri, de exemplu, va înlocui domeniul în datele serializate).

Mediul de staging

Când commit-urile sunt trimise din ramura develop către gitosis, acestea sunt automat implementate pe serverul nostru de staging. Baza de date de staging este un slave pentru baza de date de producție.

Mediul de producție

Când commit-urile sunt trimise către gitosis pe ramura master, acestea sunt automat implementate pe serverul de producție.

Problema wp-config.php

Doriți ca wp-config.php să fie unic de la un server la altul, dar doriți și să-l păstrați sub controlul versiunilor. Soluția mea a fost să folosesc .gitignore pentru a ignora wp-config.php și să păstrez versiunile de staging și producție ca fișiere cu nume diferite. Apoi, pe fiecare server, creez un symlink, de exemplu wp-config.php -> wp-config-production.php. Fiecare utilizator își păstrează propria bază de date cu propriile credențiale, cu propriile setări (netrack-uite) wp-config.php.

Alte note

Folosesc Rackspace Cloud, care este fenomenal și ieftin. Cu el, pot menține serverele de staging și producție identice. De asemenea, acum scriu plugin-uri care folosesc API-ul lor pentru a-mi permite să controlez serviciile direct din WordPress, este minunat.

Directoarele de cache, directoarele pentru încărcarea fișierelor etc., sunt toate adăugate în .gitignore. Dacă doriți, ați putea configura o sarcină cron pentru a verifica în mod regulat încărcările și a le trimite către gitosis, dar asta nu mi s-a părut niciodată necesar.

Structura master/develop este configurată pentru a imita parțial modelul de ramificare al lui Vincent Driessen. Folosesc și extensia sa pentru git, git-flow, și aș sugera și aceasta cu mare încredere.

Am avut aproximativ 10 dezvoltatori care au lucrat cu această structură de peste un an și a fost o experiență fantastică. Fiabilă, sigură, rapidă, funcțională și agilă, nu poți cere mai mult!

În primul rând, cred că este important să iei în considerare ce vei controla versiunile. Aș recomanda împotriva includerii întregului director WordPress în controlul versiunilor. Cred că are cel mai mult sens să pui wp-content/themes/NumeleTemei tale sub controlul versiunilor. Pentru un site mare cu un număr mare de pluginuri complexe, aș putea vedea cazul în care să incluzi și wp-content/plugins. Dacă este absolut necesar, ai putea include și wp-content/uploads. Răspunsurile de mai jos se vor schimba puțin, în funcție de ce controlezi versiunile.

Având în vedere acestea, iată ce folosesc eu:

Local: Configurează un mediu LAMP pe mașina ta. Folosește același URL ca și site-ul de dezvoltare. Utilizează VirtualHosts și intrări în fișierul .host pentru a simula mediul de dezvoltare din punct de vedere al URL-ului. Dacă controlezi versiunile doar pentru tema ta, ia în considerare utilizarea SSHFS pentru a te conecta la wp-content/plugins, wp-content/uploads. Ia în considerare utilizarea bazei de date de pe instalarea de dezvoltare a proiectului, decât dacă lucrezi la ceva foarte complex.

Dezvoltare: Verifică o copie de lucru a depozitului tău în mediul WordPress. Configurează un POST-COMMIT Hook în SVN pentru a actualiza acest depozit la fiecare commit. Acest lucru îl va menține sincronizat. (Consideră-l o formă simplistă de integrare continuă.)

Producție: Verifică o etichetă de versiune numită care reprezintă o versiune finală. Când ai nevoie să folosești o nouă versiune, schimbă eticheta și actualizează depozitul.

Am descoperit recent RAMP. Notă: acesta este doar o parte din întregul proces, dar sincronizarea bazelor de date de conținut între servere este probabil cea mai dificilă parte a acestuia.

Eu fac asta cu git și mercurial, doar asigură-te că folosești un repository privat.

Opțiunea 1.

Singura problemă este config.php, pe care poți să-i spui git să-l ignore la push sau înainte de init.

Folosește .gitignore sau git update-index --assume-unchanged config.php (citește puțin despre comanda assume-unchanged înainte să o folosești)

Opțiunea 2.

Folosește o condiție în config.php care verifică URL-ul și aplică credentialele corecte, ceva de genul "dacă URL server = dev atunci folosește credentialele A, altfel folosește credentialele B", etc.

Mark explică asta mai bine, http://markjaquith.wordpress.com/2011/06/24/wordpress-local-dev-tips/

ps. Poți servi fișierele direct dintr-un repository remote în loc să ai un "file server" tradițional. (video plictisitor pe care l-am făcut despre asta http://www.youtube.com/watch?v=8ZEiFi4thDI )