Share
În această serie, analizăm diferitele practici utilizate în dezvoltarea WordPress profesională. În articolul precedent, am analizat un set de strategii și materiale de referință care sunt utile atunci când se creează teme, pluginuri și aplicații bazate pe WordPress.
În acest articol, vom analiza configurațiile de control al versiunilor și de mediu, care facilitează dezvoltarea, testarea și desfășurarea activității noastre pentru a minimiza cantitatea de erori care se găsesc în versiunile finale ale activității noastre.
Acest subiect nu este nimic nou. De fapt, mi-ar place să spun că majoritatea cititorilor sunt familiarizați cu Subversion și / sau Git (mai ales cu popularitatea lui GitHub). Ca atare, punctul din acest articol nu este atât de mult de a da un tur al diverselor sisteme de control al surselor sau de a face un caz pentru care ar trebui să utilizați, dar este menit să facă un caz pentru De ce ar trebui să utilizați controlul sursă și modul în care este legat de mediile noastre.
Daca esti complet nou pentru conceptul de control al versiunii, să oferim o definiție simplă, din care să putem lucra astfel încât să ne aflăm pe aceeași pagină:
Controlul versiunilor este un instantaneu al codului dvs. sursă în orice perioadă de timp, care vă permite să vă răsturnați când este introdus un bug și să lucrați la o nouă caracteristică fără a întrerupe codul existent.
În cadrul comunității WordPress, oamenii sunt adesea împărțiți în privința faptului că trebuie sau nu să ia în considerare teme și / sau programe de pluginuri sau site-uri glorificate. Personal, cred că sunt o formă de software deoarece sunt supuse multor aceleași practici:
În acest scop, dezvoltarea și menținerea muncii specifice WordPress ar trebui tratată ca atare și este standardul industrial pentru a oferi un nivel de control al versiunii software.
În plus, controlul versiunilor funcționează împreună cu lucrul la proiectul dvs., testarea acestuia și apoi implementarea acestuia pe un server live pentru alții să îl folosească.
Majoritatea dezvoltatorilor sunt familiarizați cu diferitele medii, chiar dacă nu folosesc terminologia exactă. Pur și simplu definit:
Destul de simplu.
Chestia este că fiecare dintre aceste medii este, de asemenea, strâns legată de controlul versiunii, astfel încât atunci când este administrată corect, puteți reduce la minimum cheltuielile de întreținere a versiunilor și a implementării lucrării dvs..
Mediul de dezvoltare este mașina pe care vă dezvoltați proiectul. Acesta include o copie a WordPress, serverul web, serverul de baze de date, IDE și instrumentele conexe pe care le utilizați pentru a vă construi proiectul.
Acest mediu particular este locul în care ar trebui să faceți comiteri frecvente. Prin aceasta, vreau să spun că de fiecare dată când faceți o schimbare semnificativă - fie o caracteristică nouă, o rezolvare de bug-uri sau ceva similar - atunci ar trebui să comiteți un cod în depozit.
Aici, avantajul este că puteți reuși să răsturnați cu ușurință, să identificați și să distingeți între schimbări dacă ceva nu merge bine în timpul procesului.
După ce ați finalizat o cantitate semnificativă de modificări (în cazul în care dvs. sau echipa dvs. stabiliți ce reprezintă "semnificativ"), atunci este momentul să marcați setul de modificări și să vă deplasați în mediul de așteptare.
Mediul de etapizare este un server separat care seamănă cu mediul de producție, dar este folosit pentru a testa proiectul înainte de a-l elibera. Acesta include cea mai recentă versiune a codului, datele de testare și este destinată utilizatorilor să evalueze proiectul înainte de al elibera. Nici o dezvoltare nu ar trebui să apară aici.
Deși nu ar trebui să apară aici nicio dezvoltare, nu este neobișnuit să existe diferite instrumente de depanare pentru a genera mesaje de jurnal sau pentru a revizui ce se întâmplă și a ieși din baza de date în timp ce lucrați pe site.
Întrucât dezvoltatorii comit adesea un set de modificări la depozit, trebuie să fie testate. Aici intră în joc mediul de scenă. În general, mediul de așteptare corespunde deseori ultimului set de modificări aduse depozitului.
Dar aceasta ridică două întrebări:
În primul rând, acesta este un lucru bun - înseamnă că mediul de etapă a servit scopului său! În plus, ne dă șansa să ne revedem codul sursă pentru a determina dacă o eroare trebuie rezolvată sau trebuie introdusă o nouă caracteristică.
Și aici este locul unde controlul surselor vine la îndemână.
Dacă a apărut o eroare, puteți să vă aplecați în direcția de a schimba schimbarea, dar în mediul de așteptare nu este necesar. În schimb, pur și simplu localizați unde este bug-ul, rezolvați-l, comiteți codul și apoi redenumiți codul în mediul de etapă pentru testare.
Repetați acest proces până când nu există bug-uri sau, cu precizie, nu puteți găsi nici un bug.
Dacă nu reușiți să localizați vreo eroare, atunci ați obținut în mod esențial ceea ce se numește construcție stabilă. În acest moment, puteți eticheta - sau ștampila, eticheta sau orice convenție pe care sistemul de control sursă le oferă - o versiune a codului dvs. și o implementați în mediul de producție.
Desigur, există șansa ca un bug să poată fi descoperit după ce a fost trimis în mediul de producție. În acest caz, ar trebui luate măsuri speciale.
Mediul de producție este sinonim cu site-ul live. Acesta este locul în care utilizatorii reali creează, gestionează și interacționează cu datele reale. Nici o dezvoltare nu ar trebui să apară aici.
Este foarte puțin de spus despre mediul de producție în ceea ce privește dezvoltarea. La urma urmei, acest lucru nu ar trebui să fie mai mult decât în cazul în care codul sursă este implementat pentru alții.
Dar există o șansă ca un bug să poată fi eliberat aici. Când se întâmplă asta, acest este atunci când ar trebui să apară o retrogradare. Pur și simplu puneți-o înapoi, atunci când luați cel mai recent set de modificări și literalmente anulați implementarea restaurând proiectul în starea sa anterioară.
Înainte de a efectua o revigorare, merită luați în considerare pașii de recreație, astfel încât să puteți să-l reproduceți atât în mediul de etapizare, cât și în mediul de dezvoltare, pentru a rezolva corect problema.
De aici, efectuați dezvoltarea necesară pentru rezolvarea problemei, efectuați o altă schimbare, implementați-o în mediul Staging și deplasați-o în mediul de producție, presupunând că trece testul.
Evident, acest post special acoperă conceptele la nivel înalt: nu explorăm sistemele de control al versiunilor care sunt cele mai bune și nici nu ne uităm la instrumentele care sunt cele mai bune pentru sistemul dvs. de operare. Aceste subiecte sunt în afara scopului acestui post și merită fiecare din seria proprie.
Cu toate acestea, în cadrul conceptului de WordPress Professional Development, aceste practici se pot dovedi utile în dezvoltarea, testarea și implementarea (și rularea) versiunilor proiectului.
În postarea finală, vom examina câteva dintre instrumentele disponibile care ne vor permite să diagnosticăm multe erori în mediul nostru de dezvoltare local cu intenția de a împiedica mulți dintre ei să ajungă chiar la mediul de etapizare.
Accentsconagua