Intr-o incapere intunecata pe care hackerul sta, a incercat ore in sir sa obtina acces la tinta sa, scrisa verde pe un terminal negru care clipeste, in timp ce el mestesuga sarcina utila. Acest atac va fi cel care ii va permite sa intre. Tocmai in acest moment, culmea de succes vine mama ei cu ceasca de ceai. 

Pentru majoritatea oamenilor, acest lucru considera ca arata un actor rau, un individ sau un grup solitar pentru a-i viza. Realitatea, desigur, este ca majoritatea hack-urilor sunt facute in intregime automatizate, fara ca niciun om sa introduca vreodata o singura comanda in serverul tau acum inradacinat. 

Odata cu inceputul noului deceniu, m-am gandit sa arunc o privire asupra elementelor de baza ale securitatii WordPress pe care le asumam adesea si sa consideram cum in 2020 putem atinge un nivel minim de securitate care isi propune sa elimine 99% din automatizari atacuri.

Acest articol este mai putin interesant, mai degraba o privire asupra strategiilor de actualizare pentru agentii si site-uri, chiar si pentru cele care considera ca sunt critice pentru misiune. Cu strategia corecta in vigoare si modul de testare a actualizarii este usor si ceva care nu ar trebui sa va tina pasul noaptea. Cu toate acestea, desi nu este o modalitate de a include instrumente si tehnici care ar trebui utilizate.

De ce actualizati?

Pare banal, atat de evident si totusi poate chiar daca nu esti atent sa se dovedeasca a fi aproape imposibil de facut, dar prima modalitate de a pastra software-ul in siguranta este sa-l pastrezi patat si actualizat.

Majoritatea actorilor rai (atacanti rau intentionat) nu folosesc instrumente extrem de inteligente pentru a va ataca site-urile, ci se bazeaza pe vulnerabilitatile cunoscute si codul scris de altii pentru a exploata site-ul dvs. si alte mii de persoane in mod automat. 

Sa presupunem ca aveti un plugin pentru widgets albastre si are o vulnerabilitate care permite incarcarea unui fisier pe serverul web fara verificari. Acesta este un praf destul de rau si de aur pentru actorii nostri rai. Cu toate acestea, s-au intamplat mai multe lucruri, numarul unu, actorul nostru rau trebuie sa stie despre site-ul dvs. si numarul doi de care trebuie sa stie despre vulnerabilitate, precum si cum sa-l exploateze.

Deci, cum va gasesc site-urile dvs. actorii rai? Ei bine, prima modalitate este ca site-ul dvs. este deja cunoscut pentru ei si, probabil, este vizat in mod special, acest lucru este incredibil de rar, chiar si mai mari hack-uri de marci cunoscute, nu pornesc, deoarece site-urile dvs. pot fi tinta unui actor rau fie din motive politice, economice, de stat sau doar rautate. 

Al doilea motiv mult mai probabil este ca site-ul dvs. a fost gasit in timpul unei scanari automate, cautand conditii care ar putea-l face exploatabil, de exemplu, site-ul dvs. ar putea fi tinta, deoarece o scanare a dezvaluit ca aveti pluginul pentru widgeturi albastre. In acest scenariu site-ul dvs. nu este obiectivul, ci este folosit pur si simplu pentru a avea acces la server. Atacurile automatizate pot fi destul de specifice, incercand doar o singura vulnerabilitate, dupa ce au verificat existenta unor astfel de conditii sau exista o abordare totala a imprastierii, acceptarea site-ului dvs. este sus, prin urmare, sa incercati cat mai multe exploatari pana se poate bloca, sperand ca reuseste.

Site-urile sunt foarte rar vizate si este trist, dar important sa intelegem ca sunt adesea doar daune colaterale pe parcursul resurselor serverului din spatele lor. Exista exceptii, in special in ceea ce priveste site-urile de comert electronic, unde skimmerii cu carduri de credit devin o amenintare din ce in ce mai mare, dar in general, daca site-ul dvs. nu a fost directionat in mod specific, este doar o modalitate de a accesa serverul.

Deci, cum apar vulnerabilitatile? Pentru Widget-ul nostru Blue Plugin, cineva trebuie sa stie ca exista o vulnerabilitate si sa scrie codul pentru a-l exploata. Un actor rau poate identifica o vulnerabilitate, s-ar putea sa o rataceasca sau sa priveasca un anumit plugin ca o potentiala tinta. Este posibil ca un cercetator de securitate sau autorii pluginului sa identifice problema si sa-l corecteze. Cand o vulnerabilitate este gasita, de catre un actor rau sau publicata ca informatii de catre autorul pluginului / cercetatorul de securitate, informatiile au tendinta de a fi diseminate rapid. Ceea ce porneste de la „aceasta este o problema potentiala”, schimbarile rapide la aceasta reprezinta o dovada a conceptului cu privire la modul de exploatare a acesteia, aici este o versiune „armata” a exploitului, pentru a fi implementata in cadrul de exploatare disponibil public.

Vestea buna daca este descoperita o vulnerabilitate, in mod normal, dezvoltatorii iau masuri pentru a-si corela codul si pentru a remedia erorile care permit vulnerabilitatea, atunci ele lanseaza aceasta corectie ca o versiune noua. Deci cum sa oprim cele mai multe atacuri? 

Actualizam.

Actualizari de securitate vs remedierea lucrurilor

In lumea perfecta, nucleul WordPress ar avea un fel de cicluri de eliberare a securitatii pe termen lung, in care corectiile de securitate sunt eliberate independent de orice altceva. Cu siguranta, unele versiuni minore sunt denumite versiuni de corectie de securitate, dar adesea, corectiile de securitate sunt completate cu remedierea erorilor generale. 

WordPress core accepta tehnic doar cea mai recenta versiune a WordPress.

Cu toate acestea, echipa de securitate sustine erori critice de securitate, asa ca atunci cand exista o problema majora, cea mai recenta versiune a WordPress primeste o versiune minora, dar toate ramurile / relevantele se intorc pana la 3.7. Cel putin in prezent, pe masura ce WordPress lanseaza din ce in ce mai mult acest proces devine din ce in ce mai impovaratoare si aceasta politica este in curs de revizuire, astfel incat nu este sigur sa presupunem nimic, dar ultima versiune este considerata patch.

Toate acestea sunt doar nucleu WordPress, teme si plugin-uri au fiecare ciclul lor de viata de revizuire, dar majoritatea nu suporta versiunile de securitate. Cele mai grave pluginuri si teme nu declara corectii de securitate, lasandu-le ca fiind corecti cateva bug-uri, element rand in Changelog. In consecinta, doar cea mai recenta versiune a unui plugin sau a unei teme este probabil cea cu cele mai recente corectii de securitate.

Nu este atat de usor de actualizat

Sau poate este, WordPress are o procedura de actualizare manuala foarte simpla, va conectati la Panoul dvs. de administrare si sub Panoul de bord, exista Actualizari facand clic pe aceasta lista a tuturor actualizarilor necesare, atat pentru corectia WordPress, cat si pentru pluginuri si teme. Daca faceti clic pe actualizare pe o componenta individuala sau pe actualizare, toate se vor conecta la WordPress.org si veti descarca Tema / Pluginul sau WordPress-ul corespunzator.

Cateva probleme se prezinta cu abordarea noastra implicita, in primul rand este ca se bazeaza pe un om pentru a o face si bine ca sugeam ca o cursa pentru a face astfel de lucruri. Este ca si cum am avea o fobie incorporata de butoane de actualizare, poate un trecut traumatizant sau chiar departe de a folosi Windows-ul nu reuseste ne-a inteles.

O alta problema a acestei abordari este aceea ca cineva trebuie sa fie responsabil de realizarea acesteia, un proces de cand si cum se face este necesar si, in mod ideal, este inregistrat atunci cand lucrurile se actualizeaza. Acest lucru inseamna pentru operatorii site-ului solo, nicio vacanta pentru tine fara laptop si sper ca esti sanatos. Intr-o organizatie mai mare, avem si mai multe probleme, cu cine a apasat butonul de actualizare si cand. Site-ul cu semnificatii poate avea probleme si nici nu stim ca este o actualizare, deoarece Bob a apasat butonul de actualizare pentru WooCommerce, dar nu a reusit sa actualizeze nimic altceva.

Asadar, sa lasam oamenii sa faca clic pe butoanele proaste, nu suna bine, ce alte abordari am putea lua?

Complet automatizate

Prima cale este sa acceptam ca noi, ca oameni, nu vom actualiza lucrurile si ar trebui doar sa lasam sistemul sa faca actualizarile. In mod implicit, WordPress actualizeaza deja nucleul cu actualizari „minore”, astfel incat exista sisteme in loc si adaugand cateva filtre suplimentare / teme si actualizari majore ale WordPress pot fi activate. 

add_filter (‘allow_major_auto_core_updates’, ‘__return_true’); // Actualizeaza toate versiunile add_filter WordPress Core (‘auto_update_plugin’, ‘__return_true’); // Actualizari plugin-uri add_filter (‘auto_update_theme’, ‘__return_true’); // Actualizari Teme add_filter (‘auto_update_translation’, ‘__return_true’); // Actualizari Traduceri

Este important sa intelegeti ca automatul de actualizare functioneaza folosind actualizatorul WordPress implicit, astfel incat numai pluginurile pe care le poate actualiza, vor functiona cu solutia de actualizare WordPress. De asemenea, majoritatea actualizarilor automate ale partilor terte sau WP-CLI se bazeaza tot pe acest sistem. Daca aveti pluginuri sau teme, care utilizeaza propriul actualizator si nu se conecteaza la acest sistem, atunci va trebui sa faceti pasi suplimentari pentru a obtine o automatizare completa. 

Un proces complet automat arata asa:

  • O data la 12-24 de ore, site-ul verifica actualizari folosind verificatorul WordPress standard.
  • Daca se gasesc actualizari, site-ul se actualizeaza.

Uite asta este.

Acum, acest lucru este destul de simplu, dar stim cu totii ca atunci cand actualizam ceva se rupe, iar acest lucru va fi la 2 dimineata. In cazul in care site-ul nu poate fi operat, nu avem niciun beneficiu sa fim asigurati de actori rai. Realitatea este ca esecurile se intampla foarte rar, chiar daca sunt percepute ca fiind un risc ridicat, insa un proces mai bun este:

  • O data la 12-24 de ore, site-ul verifica actualizari folosind verificatorul WordPress standard.
  • Daca se gasesc actualizari, actualizam site-ul de inregistrare cu actualizari.
  • Site-ul de inregistrare este verificat si daca nimeni nu il opreste, site-ul principal actualizeaza 24 de ore mai tarziu.

In primul nostru scenariu am putea face asta cu 3 linii de cod, acum am adaugat un site de inscenare si toate dependentele sale, trebuie sa construim si noi cu intarziere pentru site-ul nostru live. De asemenea, are problema ca se bazeaza pe acei oameni obisnuiti pentru a verifica lucrurile. Un sistem complet automat nu ar trebui sa aiba oameni implicati.

Deci, un proces mai fiabil ar fi:

  • O data la 12-24 de ore, site-ul verifica actualizari folosind verificatorul WordPress standard.
  • Daca se gasesc actualizari, actualizam un site de testare cu actualizari.
  • Site-ul de testare este apoi „testat” in mod automat. 
  • Daca testele trec, site-ul principal se actualizeaza.

Deci, din nou complexitatea noastra a crescut rapid, avem nevoie de un site de testare, in mod ideal, unul care se trage de pe site-ul live. Rularea unei serii de teste, ceea ce inseamna ca avem nevoie de un fel de test suite si apoi impingem sau reexecutam actualizarea pe site-ul live. 

Totusi, odata configurata, aceasta abordare complet automatizata ar trebui sa fie incredibil de robusta, atata timp cat acoperirea testului nostru este robusta. Intr-adevar, pentru toate abordarile de actualizare se bazeaza mult pe testare (a se vedea strategiile de testare). 

Actualizarea si nu panicarea esecurilor

Desi cea de-a treia optiune este cea mai ideala, si daca nu avem capabilitatile tehnice pentru a implementa o implementare pe mai multe etape, ar trebui doar sa automatizam si sa fim condamnati? Raspunsul este aproape sigur ca da. Majoritatea persoanelor care au esecuri in timpul procesului de actualizare se incadreaza in actualizatoarele rare sau in taberele de actualizare prudente.

In ambele cazuri, acestea nu actualizeaza sau actualizeaza mai rau selectiv si, prin urmare, nu totul este actualizat in acelasi timp, rezultatul este un plugin care ar putea avea o corectie de compatibilitate cu cea mai recenta versiune WordPress nu se actualizeaza in timp ce nucleul face. Rezultatele sunt o eroare si o teama de actualizare. Daca totul este actualizat, rata de esec scade in mod semnificativ, incat multe gazde gestionate sunt dispusi sa forteze clientii in cicluri de actualizare. In plus, desi nu este ideal ca un site sa fie in jos, putine site-uri sunt atat de critice pentru misiune incat o data la cativa ani nu isi permit sa stea peste noapte. Daca site-ul dvs. este esential pentru misiune, atunci ar trebui tratat ca atare, daca este blogul personal sau site-ul cu brosuri, atunci putem actualiza si daca exista o problema, o rezolvam dimineata. 

Beneficiile complet automatizate

  • Niciodata nu trebuie sa va faceti griji pentru actualizari
  • Durata ciclului de plasture este imediata
  • Nu exista probleme de conformitate, mereu actualizate.

Contra automate

  • Are nevoie de un sistem care sa se ocupe de testare si implementare
  • Site-ul se poate rupe si nimeni nu va fi disponibil pentru a fi
  • O cantitate mare de complexitate

Pentru cine este cel mai bine

Solutia complet automatizata este potrivita probabil pentru marea majoritate a site-urilor, cu foarte putine exceptii. Cu toate acestea, se bazeaza pe bune optiuni de plugin si tema, sistemul se incadreaza daca exista plugin-uri „suparatoare” sau bucati mari de cod de la terte parti care nu se afla in sistemul automatizat. Construirea sistemului este o investitie rezonabila si necesita realizarea de teste pentru cele mai bune rezultate. Agentiile ironic si echipele de dezvoltare cu implementari bazate pe CI (integrare continua) sunt adesea cele mai rezistente la abordarea complet automatizata, insa sunt in locul perfect pentru construirea unor astfel de sisteme, intrucat cea mai mare parte a instrumentelor lor este deja in vigoare. Daca un magazin de dezvoltare nu utilizeaza actualizari complet automatizate, atunci este o oportunitate de a-ti imbunatati masiv strategiile de implementare.

Marti Patch

Traseul 2 pe care tocmai am incercat sa-i convingem pe toata lumea ca automatizarea deplina este calea de urmat si raspunsul a fost ceva asemanator cu: Nu fi prost.

Diferitele argumente au prezentat toate defecte, dar prietenul meu nu este in masura sa le combata, incercati sa le convingeti cu rate de esec sub 1% actualizarile automate sunt sigure, ca testarea va acoperi cazurile de margine. Ati incercat sa explicati ca investitia in sisteme si procese va imbunatati implementarile de la nivel general. Totul se incadreaza pe urechile surde, atunci ai nevoie de o strategie diferita si acesta este momentul in care se onoreaza „Patch Tuesdays” cum functioneaza:

Pastrati un site local sau de inregistrare si il actualizati o data pe saptamana

  • Test
  • Apoi se implementeaza 

Tot acest proces este manual, DAR TIMP CUMPARAM UMANE. Da, dar cel putin oamenii obositi nu fac clic la intamplare pe butoane. Strategia Patch Tuesday functioneaza deoarece actualizam o data pe saptamana, indiferent. Daca nu reusim sa actualizam, nu mai avem o strategie, astfel ca vom inlocui automatizarea procesului.

Strategia Patch Tuesday inseamna ca oprim si dezactivam automat si, intr-adevar, toate actualizarile automate Patch Tuesday sunt sursa noastra de actualizare, in acest fel sunt testate intr-un singur proces.

Abordarea marti de patch are avantajele ca problemele sunt gasite in teorie inainte de desfasurare, au un lant in care exista o persoana responsabila pentru desfasurare, astfel incat ar trebui sa gaseasca probleme. Cu toate acestea, la fel ca oricare dintre rute, March Patch depinde de testare. 

Cea mai mare problema cu Patch Tuesday este atunci cand este ratata sau ceva mai rau nu este actualizat, in al doilea rand se intampla acest lucru devine un sistem care nu reuseste, iar pe masura ce diferenta dintre momentele de actualizare creste, mai multe lucruri se vor rupe, ceea ce inseamna ca Patch Tuesday devine o povara mai grava. o scuza. 

O optiune este de a automatiza marti Patch

Pentru ca executia initiala de angajare sau comanda sa fie automatizata, atunci omul este responsabil doar de testare si desfasurare. In acest fel, optiunea 2 nu este diferita in cadrul unei abordari complet automatizate, doar daca se intampla doar o data pe saptamana sau o perioada specifica, reduce aceasta povara.

Numele Patch Tuesday provine din programul obisnuit al Microsoft pentru patch-uri (le stiti pe cele care se instaleaza doar pe masina dvs., dar in intreprinderi se actualizeaza manual deoarece) 

Ruta Patch Tuesday, de asemenea, potential limiteaza modul in care codul dvs. de stocare, pentru ca site-ul este aproape sigur pentru a-l face in mod fiabil, ALL-ul codului va trebui sa fie stocat in controlul versiunii, inclusiv folderele vanzatorilor, etc. acolo, deoarece site-ul live ar primi automat cea mai recenta versiune (sau ar putea face in functie de strategie)

Pro de marti Patch

  • Problemele sunt preluate din timp si solutionate inainte de productie
  • Incorporat in optiunile de implementare existente

Cons de patch marti

  • Oameni peste tot
  • Procesul nu se codeaza greoi, prima data cand cineva nu reuseste sa corecteze sistemul
  • Este mult mai lent timpul de implementare
  • Aproape cu siguranta ramanand intotdeauna in urma unui sistem cu adevarat actualizat.
  • Limita modul in care stocati codul.

Pentru cine este cel mai bine

Incredibil de misiune site-uri critice, in cazul in care intreaga afacere este bazat in jurul site-ului si are o echipa construita in jurul sau pentru a putea functiona strategia Patch Tuesday. Echipele obisnuite deja sa lucreze in cicluri de corectii, deci atasate la IT-urile mai traditionale vor avea achizitii mai usoare pentru acest stil de implementare.

Versiunea aprobata

Route 3 este o alta strategie de lansare dezordonata, toata lumea este de acord ca adora versiunile automate, dar au WooCommerce instalat si ca nu pot fi de incredere (poate, dar stiu ca nu ma vei crede), in schimb, cu versiunea aprobata, urmam practic optiunea a doua din lansarea automata, dar cu cateva modificari:

Practic, locul de inregistrare ramane mereu actualizat, dar impingerea finala este facuta de un om pentru a trai acest lucru ii ofera unele avantaje ale Patch Tuesday si complet automatizate, dar cu dezavantajele ambelor.

Inca avem oameni obisnuiti si, intr-adevar, un om pustiu, cu un proces flexibil. Unul dintre cele mai mari avantaje ale Patch Tuesday este o structura rigida a actualizarii, ceea ce inseamna ca se asteapta actualizari la anumite puncte. Eliberarea aprobata este adhoc si cel mai rau potential este in mainile unei singure persoane.

La fel ca Patch Tuesday, aceasta strategie inseamna ca toate lucrurile trec prin stadializare / testare si astfel oprirea tuturor actualizarilor automate si chiar eliminarea optiunilor de actualizare din interfata utilizatorului impreuna. De asemenea, acest lucru functioneaza cel mai bine in strategiile in care site-ul este controlat in intregime prin ciclul de stadializare / testare cu procese de implementare dedicate. Intr-adevar, atat Patch Tuesday, cat si Release Approved functioneaza numai daca exista o singura conducta de implementare, altfel lucrurile vor fi ratate (desi versiunea aprobata, fiecare actualizare ar putea trage din live).

Beneficiile eliberarii aprobate

  • Problemele sunt preluate din timp si solutionate inainte de productie
  • Problemele pot fi reduse rapid in direct

Contra eliberarii aprobate

  • Oameni peste tot
  • Inca mai are nevoie de o solutie de implementare pentru actualizari automate pe stadializare, o modalitate de a se implementa in direct si o modalitate de notificare a actualizarilor
  • Si totusi proces continuu, daca nimeni nu apasa butonul.
  • Aproape cu siguranta ramanand intotdeauna in urma unui sistem cu adevarat actualizat.
  • Limita modul in care stocati codul.

Pentru cine este cel mai bine

Foarte putini oameni, la prima vedere o multime de dezvoltatori solo si agentii minuscule cu contracte de intretinere se vor uita la acest lucru si cred ca acest lucru este perfect, pastram controlul, dar au o solutie aproape complet automatizata. Pentru site-urile de comert electronic Patch Tuesday sau Complet automatizate sunt strategii mai bune. Din punct de vedere al securitatii si ingineriei, aceasta strategie s-ar putea sa nu se potriveasca cu niciuna, insa pot vedea anumite cazuri de afaceri in care o agentie ar dori sa adopte aceasta abordare, nu in ultimul rand, deoarece aplica o singura strategie de implementare. 

Testarea

In toate cele 3 strategii noastre, toate se incadreaza la testare, daca nu testam manual sau automat, atunci acestea vor esua. Pentru testare avem 3 categorii brute de testare:

  • Monitorizarea erorilor
  • Acceptare
  • Regresie vizuala

Monitorizarea erorilor

In forma sa cea mai simpla este sa lovesti punctele finale si sa vezi daca au o eroare PHP sau Javascript, in plus vezi daca cantitatea de erori din jurnalul de erori creste. Acest lucru poate fi usor monitorizat, atat prin procesarea jurnalului de erori, cat si navigarea pe site. Adesea Monitorizarea erorilor se poate face alaturi de testarea acceptarii (testarea acceptarii face clicul), astfel incat monitorizarea erorilor poate cauta diferente.

In plus, monitorizarea HTTP simpla, cum ar fi instrumentele de functionare uptime, poate verifica ca site-ul nu genereaza 500 de erori pe paginile date. Va rugam sa verificati pagina dvs. de pornire, pagina de conectare si orice pagini critice pentru misiune (de exemplu, puteti verifica). 

In timp ce monitorizarea HTTP ar trebui sa fie destul de instantanee, in cele din urma este vorba de cateva cereri de curl efectuate din mai multe locatii si ar putea fi facute cu usurinta cu instrumentul dvs. de functionare normala (efectuati monitorizarea uptime, nu?). Monitorizarea erorilor care are in vedere cresteri statistice ale erorilor poate dura mai mult. Combinand cu testele de baza si testele de acceptare, putem grabi cel putin analiza initiala.

Instrumente recomandate

  • Updown.Io
  • Statuscake

Testarea de acceptare

Suntem bine testele de integrare si acceptare, nu? Cand dezvoltati noi functii, acum este oportunitatea de a le reutiliza si nu doar pentru testarea copiilor de rezerva. Prin executarea testelor de acceptare pe site-urile tale de testare live / test, ar trebui sa poti identifica daca au avut loc modificari de rupere. In plus, puteti utiliza aceste monitorizari ale erorilor laterale pentru a vedea daca testarea dvs. genereaza erori suplimentare in jurnalele (sau daca jurnalele dvs. sunt zgomotoase, aceasta ar putea fi o crestere procentuala, desi in lumea noastra perfecta, jurnalul dvs. de eroare PHP ar fi gol) .

Dezavantajul testarii de acceptare este ca acestea pot fi lente, chiar si pe un site foarte neinteresant ca acesta, setul meu de teste de acceptare dureaza aproximativ un minut, cu toate ca majoritatea software-ului de testare de acceptare / integrare va permite sa grupati testele, astfel incat sa puteti rula doar prioritate mare de exemplu, post build-urile, un bun exemplu pentru acest site testele mele de acceptare:

  • Verificati incarcarile mele de pe pagina principala, inclusiv consultarea textului de subsol
  • Pagina mea de conectare, incarcarile, se pot autentifica si vi se solicita autentificarea cu doi factori
  • Feedul meu RSS se incarca si conteaza cate intrari sunt in feed

Acum, suita mea de test complet face lucruri precum testarea formularului de contact, niste biti backend si o serie de teste mici.

Lucruri despre care trebuie sa va ganditi inainte de a rula teste de acceptare in direct:

  • S-ar putea sa aveti securitate pentru a preveni o astfel de automatizare 
  • Testele dvs. de acceptare ar putea fi de natura distructiva, verificand ca stergerea tuturor functiilor de functionare a mesajelor s-ar putea sa nu fie un test bun pentru live.
  • S-ar putea sa creeze intrari in DB, de exemplu, unul dintre testele mele de acceptare creeaza o postare si o publica (de fapt, nu pentru ca Gutenberg a spart-o, asta este o postare pentru o alta zi)

Testele de selectie care au o acoperire larga in cele din urma pentru actualizari pe care doriti sa le stiti daca lucrurile functioneaza.

Instrumente recomandate

  • Codeception 

Interesat de testarea acceptarii Am vorbit la WordCamp London 2015 despre introducerea testarii de acceptare.

Testare de regresie vizuala

Testul de regresie vizuala suna foarte fantezist, dar inseamna literalmente compararea iesirii site-ului dvs. cu o versiune anterioara pe care ati luat-o. Acest lucru se face in mod normal prin ecranizarea site-ului dvs. inainte si dupa, apoi comparandu-le, daca exista o diferenta procentuala intre cele doua, atunci acesta este indicat. O regresie vizuala „slaba” nu inseamna sa folosesti iesirea redata (adica capturi de ecran), ci pur si simplu pentru a evalua DOM, aceasta are un nivel mai ridicat de falsuri pozitive, deoarece chiar o usoara modificare a elementului, de exemplu, un plugin care actualizeaza DOM-ul pentru a-l curata. up poate duce la schimbarea oricarui alt element.

Testarea regresiei vizuale poate fi foarte simpla sau foarte usor de configurat in functie de cazurile de utilizare, exista servicii terte precum VisualPing care va compara capturile de ecran din zilele anterioare. 

Instrumente recomandate

  • Codeception – VisualCeption
  • VisualPing

ACTUALIZEAZA TOATE CATTURILE !!!

Totul are nevoie de o actualizare din cand in cand, iar obiectivul tau este sa il faci cat mai usor de actualizat. Pentru marea majoritate a persoanelor si companiilor care sunt complet automatizate este raspunsul chiar si fara o acoperire completa a testului, rata de esec este atat de scazuta incat sa fie acceptabila pentru toate site-urile critice, cu exceptia celor mai absolute. Pentru acele site-uri critice de misiune care nu pot fi complet automatizate, atunci derularea strategiilor Patch Tuesday minimizeaza problemele potentiale ale actualizarii Adhoc.

In toate cazurile, actualizarea nu reuseste, atunci cand nu este facuta in mod constant, pastrarea lucrurilor la zi s-ar putea simti descurajant daca te uiti la un ecran cu o suta de plugin-uri care au nevoie de actualizare, dar odata ce ai deasupra, procesul poate fi fara probleme si nu va trebui niciodata sa te mai gandesti la asta.

Este important sa va amintiti, desi WordPress este doar o parte a stivei si, prin urmare, nu doar actualizarea WordPress, plugin-uri, teme, dar tot ce se afla in dedesubt, daca gestionati propriul hosting, atunci veti avea nevoie de strategii pentru actualizarea sistemului de operare si a tuturor celorlalte aplicatii din aceasta.

Indiferent de traseul pe care il parcurgeti, stiti acest lucru pe care trebuie sa il actualizati si sa il tineti la curent cu actualizarile daca ceva va impiedica sa faceti acest lucru, este problema si ar trebui considerat un blocant. 

Ajuta-i pe altii sa gaseasca aceasta postare:

Acest post a fost scris de Me, Tim Nash Scriu si vorbesc despre WordPress, Securitate si Performanta.

Daca v-a placut, va rugam sa o impartasiti!

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR