Implementări moderne pentru site-urile dvs. WordPress

Dacă sunteți ca mine, prima dvs. experiență de a împinge fișiere pe un server web a fost fie printr-un manager de fișiere bazat pe web, cum ar fi cPanel, fie printr-un client FTP (File Transfer Protocol) precum Transmit sau Filezilla. Conectați-vă la server, trageți fișierele și așteptați finalizarea transferului.

Ușor, nu?

Cu toate acestea, de îndată ce am început să lucrez cu ceva mai complex decât fișierele HTML statice, implementarea codului meu a devenit mult mai complexă: ce se întâmplă dacă ratez un fișier care este cerut de alții sau un punct și virgulă într-o includere globală și ecranează în alb tot site-ul? Ce se întâmplă dacă un pas crucial este ratat în timpul procesului?

Aceste probleme de „codificare cowboy” doar se agravează pe măsură ce se implică mai mulți oameni, medii și dependențe. Ca rezultat, devine din ce în ce mai greu să continui să faci progrese în timp ce jonglați cu toate aceste părți în mișcare. Cel mai rău dintre toate, lansarea codului devine o mare problemă și o sursă constantă de anxietate.

Pe măsură ce aplicațiile, site-urile și magazinele noastre devin din ce în ce mai modernizate, ar trebui să ne modernizăm și implementările. De la controlul versiunilor la livrarea continuă, un proces modern de lansare poate ameliora anxietatea legată de implementări.

Urmărirea modificărilor cu controlul versiunilor

Primul pas pentru a vă îndepărta de actualizările ad-hoc și de codificarea cowboy este să vă puneți site-ul sub controlul versiunilor, folosind un instrument precum Git.

Utilizarea controlului versiunii înseamnă că veți putea vedea ce s-a schimbat, cine a făcut modificările și chiar veți putea lucra la mai multe seturi de modificări în același timp, folosind ramuri. Ca rezultat, munca nu este suprascrisă și orice conflict între fișiere este clar evidențiat.

Dacă nu ați mai lucrat cu Git până acum, nu vă temeți: am scris atât o introducere la Git, cât și o postare despre fluxurile de lucru Git mai avansate.

Decizi ce să urmărești

Pe măsură ce ne mutăm site-ul sub controlul versiunilor, ceea ce nu ținem evidența este aproape la fel de important ca ceea ce facem:

În general, controlul versiunilor este pentru urmărirea codului sursă, nu a activelor generate de instrumente sau procese . Acestea includ lucruri precum CSS și JavaScript concatenat/minimificat, dependențe externe etc. În mod colectiv, ne referim la aceste elemente drept artefacte .

De exemplu, dacă utilizați un preprocesor CSS precum Sass, fișierele CSS generate nu ar trebui să fie urmărite sub controlul versiunii. Nu numai că sunt ușor de reprodus, dar sunt greu de citit și sunt o sursă comună de conflicte de îmbinare atunci când sunt implicați mai mulți dezvoltatori.

Când vine vorba de dependențe (biblioteci, pluginuri WordPress, etc.), profitați de instrumente precum Composer și WPackagist, mai degrabă decât de gruparea codului pentru care nu sunteți responsabil în depozitul dvs.

În plus, un depozit Git nu ar trebui să conțină niciodată lucruri precum parole, chei private SSH sau orice alte informații confidențiale care ar fi considerate secrete , deoarece fiecare dezvoltator cu o copie a depozitului ar avea atunci acele informații sensibile pe computerele lor.

Structurarea depozitului dvs

Când configurați un depozit Git pentru un site WordPress sau WooCommerce, este, în general, cel mai bine să tratați wp-content/ ca rădăcină a depozitului, deoarece, în general, nu veți atinge fișierele de deasupra acestui director.

Pluginurile și temele pe care site-ul dvs. le folosește, dar pentru care nu mențineți codul ar trebui apoi încărcate prin Composer, deoarece sunt dependențe externe. De asemenea, fișierele CSS și JavaScript procesate ar trebui excluse prin fișierul .gitignore, deoarece aceste artefacte vor fi create pentru noi ca parte a procesului nostru de lansare.

Avem un șablon de depozit gratuit disponibil pe GitHub pentru a începe.

O introducere în CI/CD

Când vine vorba de implementarea software-ului, există doi termeni importanți de înțeles: Integrare continuă (CI) și Livrare continuă (CD).

Acești doi termeni sunt strâns legați, atât de mult încât sunt adesea denumiți colectiv ca „CI/CD”, iar calea prin care curg schimbările noastre devine astfel „conducta CI/CD”. Această conductă ia de obicei următoarea formă:

1. Construiți versiunea: instalați dependențe (Composer, npm etc.), apoi construiți artefacte (Webpack, Grunt, Sass etc.)
2. Testați construcția: executați teste unitare, verificați standardele de codare, efectuați analize statice de cod etc.
3. Implementați versiunea în unul sau mai multe medii

Integrarea continuă este procesul de testare continuă a codului nostru pentru a ne asigura că modificările nu distrug funcționalitatea existentă, astfel încât noile noastre modificări să se integreze în mod curat cu baza de cod existentă. Ori de câte ori sunt introduse noi modificări, se efectuează verificări pentru a ne asigura că nu „rupem construcția”.

Pentru ca integrarea continuă să fie utilă, aceste verificări trebuie să fie automatizate. De exemplu, dacă aveți o suită de teste unitare, puteți alege să rulați această suită de teste de fiecare dată când este deschisă o nouă solicitare de extragere, avertizându-vă despre posibile defecțiuni înainte ca codul să intre în producție.

Cu toate acestea, integrarea continuă nu se limitează la testele unitare, deoarece există o serie de verificări „fără cod” care pot fi executate automat împotriva codului dvs., inclusiv:

• Verificări ale standardelor de codare (PHP_CodeSniffer, PHP Coding Standards Fixer)
• Analiza codului static (PHPStan, Psalm)

Rularea automată a acestor verificări la fiecare push asigură, de asemenea, că tot codul este rulat prin aceleași verificări, prevenind eliberarea codului care nu trece.

Livrarea continuă , pe de altă parte, este ideea că ar trebui să fim capabili să „livrăm” (desfășuram) codul nostru în orice moment dat. Pentru a realiza acest lucru, trebuie să avem un proces de implementare scriptat care, cu un clic pe un buton, va muta fără probleme codul nostru în producție.

Având implementările dvs. scriptate înseamnă că puteți implementa atât regulat , cât și consecvent ; fiecare implementare ar trebui să funcționeze la fel ca cea anterioară. Ca rezultat, echipa ta se poate desfășura mai regulat, cu un nivel mai ridicat de încredere și mai puține griji că cineva a ratat un pas pe parcurs. Pentru unele echipe, nu este neobișnuit să desfășoare zeci (sau chiar sute) de ori pe zi!

În funcție de site-ul dvs., este posibil să doriți chiar să căutați „celălalt CD”, Implementare continuă ; este foarte asemănător cu livrarea continuă, dar sub acest model fiecare împingere către o sucursală este implementată automat. Acest lucru poate fi extrem de puternic atunci când utilizați o schemă de control al versiunilor ramificate (cum ar fi Github Flow), dar poate fi nedorit dacă trebuie să programați ferestre de lansare sau să faceți toate lucrările în ramura principală.

Implementarea unui site WordPress sau WooCommerce cu CI/CD

Acum că avem o înțelegere a terminologiei de bază, să aruncăm o privire la implementarea unui site WordPress tipic sau WooCommerce:

Pentru acest exercițiu, vom folosi Branch, un instrument CI/CD conceput în funcție de nevoile dezvoltatorilor WordPress de la aceiași oameni din spatele WP Pusher. Cel mai bine, Branch are suport încorporat pentru implementarea în Nexcess!

Pentru a începe, înscrieți-vă la Branch conectându-vă contul GitHub, GitLab sau Bitbucket, apoi creând primul site.

În continuare, vom dori să configuram toți pașii necesari pentru a construi site-ul nostru. Branch oferă o serie de „rețete” pentru acțiuni comune (instalarea dependențelor Composer, rularea Webpack etc.), dar ne oferă și posibilitatea de a adăuga orice număr de pași personalizați.

Odată ce am subliniat pașii necesari pentru a construi site-ul nostru, putem trece la următoarea etapă a conductei noastre: testarea.

Dacă aveți deja o suită de testare automată pentru site-ul dvs., puteți pur și simplu să îi spuneți lui Branch să execute orice comenzi sunt necesare. Chiar dacă nu aveți deja teste, Branch face ușor să adăugați scame, standarde de codare și verificări de compatibilitate.

Acum că ne-am instalat dependențele, am construit totul și am trecut testele, este timpul să punem codul în producție!

Branch conține rețete pentru implementarea la Nexcess (precum și la alți furnizori importanți de găzduire), iar conectarea celor două platforme este nedureroasă:

1. Selectați site-ul dvs. în tabloul de bord Branch, faceți clic pe „Setări”, apoi apucați cheia publică SSH a site-ului Branch.
2. Adăugați această cheie publică la lista de chei din portalul Nexcess

Odată ce Branch poate comunica cu site-ul dvs. Nexcess, putem selecta rețeta de implementare „Nexcess” și putem completa câteva detalii:

1. Numele de gazdă și numele de utilizator pentru site (disponibil prin portalul Nexcess pe ecranul „Acces” al site-ului dvs.)
2. Rădăcina web în care vom implementa. Dacă repo-ul nostru git este menit să servească drept director wp-content/, această valoare ar trebui să fie „public_html/wp-content”.
3. Fișierele pe care dorim să le implementăm (în general, implicit, „*”, este suficientă)
4. Ramura git de implementat în acest mediu

Setarea „Git branch” este deosebit de importantă, deoarece aceasta vă permite să specificați diferite implementări pentru diferite ramuri. De exemplu, este posibil să aveți o ramură de „proiectare” care se implementează în mediul dvs. de pregătire, permițându-vă să testați modificările înainte de a le pune în aplicare.

Este de remarcat faptul că Branch utilizează implicit modelul de implementare continuă, unde conducta rulează cu fiecare apăsare către ramura dată. Dacă preferați mai mult un model de livrare continuă (unde trebuie luate unele acțiuni manuale), ați putea lua în considerare menținerea unei ramuri de „producție” care se îmbină numai atunci când sunteți gata de lansare.

În acest moment, Branch ar trebui să fie configurat pentru a construi și a implementa depozitul dvs. git în Nexcess! Puteți declanșa prima implementare fie făcând clic pe butonul „Run Deployment” de pe pagina „Pipelines” a site-ului dvs., fie apăsând în depozitul dvs. Git.

Personalizarea procesului de lansare

Una dintre caracteristicile cu adevărat frumoase ale Branch este capacitatea de a configura pași suplimentari după o implementare cu succes, cum ar fi ștergerea automată a memoriei cache a obiectelor site-ului dvs. după o implementare. Acest lucru poate fi realizat folosind rețeta WP-CLI sub „Altele”.

Gazda și numele de utilizator vor fi, în general, aceleași cu cele pe care le-am folosit în etapa de implementare și puteți înlănțui câte comenzi este necesar.

Concluzie

Dacă încă te confrunți cu trăsăturile de codare de cowboy și/sau cu lansări pline de anxietate, aruncă o privire la Branch și faci implementări ușor!