Preview environments din GitHub: cum testezi înainte de producție
Cum folosești un mediu temporar pentru un branch sau pull request ca să verifici aplicația înainte de deployment-ul de producție.
Un preview reduce diferența dintre „merge” și „producție”
Un preview environment este o instanță separată a aplicației, creată pentru un branch, pull request sau build temporar. Scopul este să verifici versiunea reală rezultată din cod înainte să înlocuiești aplicația de producție.
Preview-ul nu înlocuiește testele automate, dar permite verificări care depind de build, routing, configurare și integrarea mai multor componente.
Nu reutiliza automat datele de producție
Un mediu temporar nu ar trebui să primească implicit acces complet la baza de date sau la credentialele de producție. Folosește valori separate sau acces limitat atunci când testul nu are nevoie de date reale.
Dacă preview-ul poate trimite email, procesa plăți sau apela API-uri externe, activează moduri de test sau credentiale dedicate unde furnizorul le oferă.
Configurează variabilele pentru mediul respectiv
Preview-ul poate avea alt hostname și alte servicii dependente. Verifică URL-ul public, callback-urile, CORS, autentificarea și webhooks înainte de test.
Pentru structurarea configurării, vezi Variabile de mediu în Node.js.
Ce verifici într-un preview
Alege fluxurile cu risc, nu doar pagina principală:
- pornirea aplicației și healthcheck-ul;
- autentificarea și permisiunile;
- navigarea și rutele dinamice;
- formularele și validarea;
- upload-urile și stocarea, dacă sunt implicate;
- integrarea cu API-uri externe;
- comportamentul pe mobil și desktop;
- logurile pentru erori care nu sunt vizibile în interfață.
Preview-ul trebuie să poată expira
Mediile temporare consumă resurse și pot păstra configurări vechi. Definește când sunt șterse după închiderea pull request-ului sau după expirarea perioadei de test.
Nu păstra preview-uri abandonate ca infrastructură permanentă doar pentru că încă răspund la URL.
Ce faci înainte de promovarea în producție
Confirmă commitul testat și verifică dacă deployment-ul de producție folosește aceeași sursă. Dacă există diferențe între configurări, notează-le explicit.
Pentru probleme apărute după publicare, pregătește și procedura de rollback.
Preview sau staging permanent?
Preview-ul este util pentru versiuni scurte și izolate. Un staging persistent poate fi mai potrivit pentru teste recurente, date de test pregătite sau validări care implică mai multe echipe.
Alege modelul după fluxul de lucru; important este ca mediul de test să nu fie confundat cu producția și să nu primească acces mai mare decât are nevoie.
Testează versiunea care urmează să fie publicată
Folosește un mediu separat pentru verificări înainte ca schimbarea să ajungă pe domeniul de producție.