Implementare continuă WordPress și control versiuni cu Bitbucket

Bine, oameni buni. E timpul să mărturisim.

Dacă sunteți la fel ca mine, v-ați petrecut prima parte a anilor de dezvoltare WordPress „cowboy” – adică făcând schimbări nebunești pe site-uri live, testându-le și declanșându-le urgent cu FTP, ducând adesea la 500 de mesaje de eroare interne a serverului și pauzele la nivel de site sunt vizibile pentru vizitatorii dvs. stimați.

Deși acest lucru a fost absolut palpitant în timp ce adrenalina ți-a pompat printre degete, bătând în acel punct și virgulă uitat, pe site-urile cu mai mult de 0 vizitatori (care au observat de fapt timpul de nefuncționare), acest lucru ar începe să devină o problemă. Dacă un copac cade și nimeni nu este acolo să-l audă, scoate un sunet? Depinde de teoria umanității la care subscrii.

Cu toate acestea, dacă un site se blochează și cineva este acolo pentru a-l vedea, cu siguranță va scoate un sunet.

Implementarea continuă a WordPress a fost greșită

Introduceți site-uri de instalare, duplicați instalațiile WordPress (cel puțin în teorie) unde ar putea fi făcute modificări, apoi faceți din nou pe site-ul live odată ce totul a fost confirmat că funcționează. În timp ce acest lucru a liniștit vizitatorii, a început să ne facă dezvoltatorii să facem puțin zgomot. Dintr-o dată, a trebuit să urmărim două site-uri, să ne asigurăm că codul este sincronizat manual între ele și să testăm totul din nou pentru a ne asigura că funcționează pe site-ul live. Listele lungi și dezordonate de „asigurați-vă că schimbați acest lucru în direct” și „asigurați-vă că comutați acest lucru pe site-ul de punere în scenă înainte de a copia codul” au fost, cel puțin, deranjante. Copiile de rezervă ale acestui sistem au fost, de asemenea, un coșmar – o mulțime de foldere numite „my-theme-staging-1” și „my-theme-live-before-menu-restyle-3” și așa mai departe.

Trebuia să existe o cale mai bună și a existat.

A existat Git, care oferă dezvoltatorilor un control perfect al sursei și alte funcții. Utilizarea controlului versiunilor pentru instalațiile WordPress a accelerat și a curățat instantaneu dezvoltarea, deoarece ore nu au mai fost petrecute pentru a face copii de rezervă într-un sistem per-dezvoltator, ci de fapt pentru codare. Modificările au fost salvate și am putut, în sfârșit, să adaug mesaje semnificative muncii mele, lumi diferite de „tema-mea-4-v2”.

Deși baza de cod a fost mult mai curată, problema a rămas în continuare cu implementările reale și să se asigure că site-ul în cauză folosea cel mai recent cod - introduceți oportunitatea pentru eroare umană. Să te bazezi în continuare pe încărcări FTP manuale care suprascriu codul anterior nu a fost grozav. Deși existau alte servicii CI/CD, multe dintre ele au venit cu o etichetă de preț substanțială și o cantitate mare de configurare - refigurarea serverului, bazându-se pe un alt serviciu chiar și pentru cel mai simplu site web, învățând întregul „mod de a face” al celuilalt serviciu și toate idiosincraziile care vin cu el.

Deși se pot face setări similare cu acest tutorial cu GitHub/GitLab și alte servicii, mi-am pus ouăle în coșul Atlassian devreme datorită depozitelor lor private gratuite (care a fost doar o ofertă recentă de la GitHub). Când Bitbucket și-a introdus serviciile Pipelines and Deployments , a permis noului cod să fie implementat automat pe site-urile de realizare sau de producție (sau orice alt site intermediar) fără reîncărcare prin FTP sau folosind un serviciu extern. Dezvoltatorii ar putea acum să folosească toate valorile controlului sursei în dezvoltarea lor WordPress și să trimită instantaneu acele modificări către destinațiile corespunzătoare, fără clicuri sau apăsări suplimentare, cu starea tuturor vizibilă printr-un singur tablou de bord. Acest lucru asigură că totul rămâne sincronizat și, dintr-o privire, vă permite să știți exact ce cod rulează fiecare site. În plus, prețul pentru minutele de compilare Bitbucket este incredibil de accesibil - cu 50 de minute gratuite pe lună și o opțiune pentru un plan „Free with Overages”.

A fost nevoie de puțin timp de pornire pentru a afla cum să utilizați cel mai bine ramurile și alte caracteristici ale controlului sursei în acest nou model și detaliile configurației Bitbucket Pipelines. Iată procesul pe care îl folosesc pentru a începe noi proiecte WordPress. Nu voi aborda toate aspectele esențiale despre configurarea instalării git și WordPress, deoarece resurse grozave pentru asta sunt doar la o căutare pe Google. În cele din urmă, fluxul de conținut va fi cam așa:

Rutina de depunere a WordPress Alexa Green

Pașii descriși aici ar trebui să fie executați după cum este necesar:

Pe Serverul Clientului

Configurați un domeniu pentru site-ul live (de exemplu, clientsite.com) și un subdomeniu pentru staging (de exemplu, staging.clientsite.com).

Instalați WordPress atât pe site-ul live, cât și pe subdomeniul de staging. Acest lucru se poate face prin cPanel/Softaculous (dacă găzduirea clientului are acest lucru) sau prin descărcarea de pe wordpress.org. Asigurați-vă că există baze de date separate pentru live și, respectiv, pentru staging.

Pe Bitbucket.com

Configurați un nou depozit. Includeți un .README pentru a ne pune în picioare.

În depozit, Setări > Conducte > Setări , apoi bifați Activați conducte .

În Setări > Conducte > Variabile de depozit , introduceți următoarele:

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password 

Reveniți la Pipelines > Settings și faceți clic pe butonul Configurare bitbucket-pipelines.yml . Selectați PHP ca limbă pe pagina următoare. Veți dori să utilizați ceva ca următorul cod. Asigurați-vă că înlocuiți versiunea PHP cu ceea ce utilizați pe serverul clientului și URL-urile/serverele FTP cu site-ul clientului propriu-zis (producție și staging) URL-uri/servere FTP.

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Faceți clic pe Commit fișier . Configurarea Pipelines va fi acum confirmată și rulată.

Dacă totul se implementează cu succes, întoarceți-vă și editați fișierul bitbucket-pipelines.yml (puteți ajunge acolo prin Pipelines > Settings și View bitbucket-pipelines.yml ). Veți dori să înlocuiți ambele locuri unde scrie git ftp init cu git ftp push and save/commit. Acest lucru va asigura că se încarcă numai fișierele modificate, economisind astfel minute de construcție. Fișierul dvs. bitbucket-pipelines.yml ar trebui să citească acum:

 image: php:7.1.29 pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com 

Adăugați o ramură numită main-dev .

Pe mașina dvs. locală

Clonați depozitul într-un director gol pe care doriți să îl utilizați pentru instalarea locală. Verificați ramura main-dev dezvoltare.

Configurați o instalare WP locală în acest director. Există multe instrumente pentru aceasta — Local by Flywheel, MAMP, Docker etc. Asigurați-vă că totul este la fel (versiunea WordPress, versiunea PHP, Apache/Nginx etc.) cu ceea ce rulează pe serverul clientului.

Adăugați un .gitignore care arată cam așa. În esență, dorim ca Git să ignore totul, cu excepția conținutului wp (pentru a preveni problemele de instalare între instalări). De asemenea, poate doriți să adăugați propriile reguli pentru ignorarea fișierelor de rezervă mari și a pictogramelor create de sistem și a fișierelor DS_Store.

 # Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

Salvați și comiteți .gitignore .

Faceți modificări și angajați-vă în consecință.

De fiecare dată când te angajezi la main-dev, acesta va declanșa o încărcare FTP pe site-ul de pregătire. De fiecare dată când vă angajați să masterați, va declanșa o încărcare FTP pe site-ul de producție. Rețineți că aceasta va folosi minute de compilare, așa că s-ar putea să doriți să faceți majoritatea modificărilor locale pe o ramură de lângă main-dev, apoi îmbinați cu main-dev odată ce ați terminat ziua.

Fuzionarea main-dev cu master va aduce toate schimbările de punere în scenă live. Puteți verifica starea conductelor și implementărilor în repo de pe Bitbucket.org.

Sincronizarea bazelor de date WordPress între instalații

Rețineți că cele de mai sus vor sincroniza numai fișierele (teme, pluginuri etc). Sincronizarea bazei de date între producție și punere în scenă devine o problemă diferită, deoarece deseori clienții fac modificări pe site-ul live care nu se reflectă pe site-ul de punere în scenă și invers.

Pentru sincronizarea bazelor de date între instalațiile WordPress, există mai multe opțiuni. În mod tradițional, puteți actualiza bazele de date importând/exportând prin phpmyadmin . Acest lucru este însă dificil, deoarece nu poate actualiza anumite lucruri care trebuie actualizate, cum ar fi permalink-urile din conținutul postării. Folosind această metodă, un instrument preferat este pluginul Velvet Blues Update URL-uri, pe care îl puteți utiliza apoi pentru a căuta/înlocui orice instanță a vechiului URL a site-ului (de exemplu, https://staging.clientsite.com) la noul site URL ( de exemplu, https://clientsite.com). Puteți utiliza acest lucru și cu căi și șiruri relative. Această metodă sfârșește prin a lăsa mult loc pentru erorile umane - dacă un șir înlocuit este scris greșit, poate cauza întregul site să se rupă și să nu poată utiliza pluginul/accesa tabloul de bord.

În timp ce un plugin precum All-in-One WP Migration oferă o funcție de căutare/înlocuire din cutie și este incredibil de ușor de utilizat, aduce și fișiere, anulând astfel valorile întregului nostru flux de lucru Pipelines. În plus, deoarece reimportează toate încărcările wp, poate duce la fișiere și timpi de încărcare uriași (deci nu este potrivit pentru mutarea modificărilor între instalări). Un plugin ca acesta este cel mai bine rezervat pentru copiile de rezervă ale întregului site în scopuri de arhivare/securitate.

VersionPress pare o soluție interesantă, dar încă nu este dovedită în multe medii de producție. Deocamdată, pluginuri precum WP Sync DB sau WP Migrate DB Pro par a fi cele mai bune soluții pentru gestionarea bazelor de date. Acestea permit tragerea/transpunerea bazelor de date între instalații, oferind în același timp opțiunea de a actualiza automat adresele URL și căile. Ei pot migra numai anumite tabele, cum ar fi wp_posts numai pentru conținutul postării, fără a pierde timpul cu reimportarea utilizatorilor și a setărilor la nivel de site. Îmi place să trag mereu de la live pentru a mă asigura că nicio dată de producție nu este suprascrisă. Iată un exemplu de configurare dacă utilizați WP Sync DB (mai multe explicații disponibile pe github WP Sync DB):

1. Pe site-ul live: Configurați WP Sync DB cu setarea „Permiteți extragerea din acest depozit” activată.
2. Pe site-ul de organizare: Configurați WP Sync DB cu setările Pull from Live. Numiți-o „în direct până la scenă”.
3. În configurarea dezvoltatorului local: Configurați WP Sync DB cu setările Pull from Live. Numiți-o „live-to-dev”.

De asemenea, este posibil să doriți să configurați o regulă „dev-to-staging” și să verificați setarea site-ului de staging pentru a permite suprascrierea bazei de date.

Încheierea

Am descoperit că aceste metode tind să funcționeze în majoritatea cazurilor de utilizare, atât în ​​dezvoltarea unui nou site web WordPress, cât și pentru reproiectarea/refigurarea unui site deja activ.

Permite implementări de cod care mențin toate versiunile site-ului la zi, fără timp/efort suplimentar de dezvoltare și logica intenționată și sigură de migrare a bazei de date pentru lucrul între site-uri. Actualizarea pluginurilor se face și în cadrul controlului sursei, astfel încât actualizările pluginurilor pot fi verificate în siguranță la punere în scenă înainte de a se angaja pe site-ul live, minimizând astfel întreruperile site-ului de producție.

Deși există cu siguranță loc de îmbunătățire pentru a aduce mai mult un flux de lucru de control al sursei în gestionarea bazei de date, până când un instrument precum VersionPress este folosit mai mult în mediile de producție, această metodă de tragere/împingere selectivă a bazei de date prin WP Sync DB sau WP Migrate DB Pro pare pentru a fi cea mai sigură metodă de a trata acest lucru. Sunteți curios să aflați ce funcționează pentru fluxul dvs. de lucru WordPress sau dacă, după toate acestea, preferați să vă luați laso și să codificați-l de cowboy!