Am intalnit situatia asta recent si nu m-am gandit niciodata daca este vreo problema.
Voi testati in productie sau nu?
Asta daca nu vrei sa dormi la noapte!
Poti sa dezvolti?
Nu o vad o practica sanatoasa. In plus poate afectezi alt ceva
Eu unul nu am facut asta.
Ai un motiv pt care ai face asa ceva?
Depinde ce intelegi prin ‘productie’.
Pe un set foarte limitat de utilizatori, se poate.
Nu e recomandat, dar se poate.
Depinde despre ce proiecte vorbim si ce fel de teste facem.
Pe proiectele de la un anumit nivel in sus, nu prea mai ai voie sa testezi in production. Mai ales daca vorbim de anumite teste care modifica date reale. Sa testezi daca iti vine un mail la inregistare, poti face si in production ca nu alterezi datele.
Daca vorbim de niste website-uri cu 50 vizitatori pe luna, iti poti permite sa pui si un if($_SERVER['REMOTE_ADDR'] === 'my_ip')
pentru ca, de obicei, acolo ai un singur environemnt.
1 Like
Sunt cazuri in care reproducerea unor bug-uri nu se poate face in alt environment.
Sau daca vrei sa verifici capacitatea server-ului, tot asa, nu poti verifica in alt fel.
In general sunt de acord ca nu trebuie sa afecteze experienta utilizatorilor reali, insa riscurile asumate prin testul in productie s-ar putea sa fie chiar folositoare utilizatorilor ulterior.
Bineînțeles 
, dar depinde de ce testezi. Plăți online, always. Also, G și FB fac teste cu/pe utilizatori zilnic, în producție.
2 Likes
Eu de regula testez in staging, unde am aceeasi baza de date ca in production.
In development am alta baza de date in care adaug automat toate scenariile posibile, sau ma rog, aproape toate. Mai completez la scenarii cand gasesc o situatie extraordinara.
Subscriu, indiferent de complexistatea proiectului, nu este indicat sa faci teste pe live.
Iar pentru a testa anumite lucruri poti crea / genera log-uri care sa reflecte exact ce doresti sa verifici, insa in nici un caz sa afectezi functionalitatea productiei.
Deasemeni este indicat sa ai un mirror cu live-ul unde poti testa / lucra cele necesare.
Mult Succces!
1 Like
Eu zic ca da. Cu feature flags sau canary deployments
1 Like
@tacheshun a punctat cel mai bine.
Un alt exemplu unde testarea în producție este utilă este interfața de utilizator.
Dacă schimbi drastic interfața de utilizator s-ar putea să pierzi utilizatori.
Dacă le dai opțiunea să încerce o nouă interfață îți poți da seama dacă utilizatorii sunt deschiși la schimbare.
As merge putin mai departe pentru ca deja suntem in epoca aia: Cand sistemul ajunge suficient de mare si complex, si exista destul de multe echipe care lucreaza in paralel incat crearea lui pe un mediu de Test/Stage devine imposibila din cauza schimbarilor dese.
Caz concret: Daca ai 7 echipe a cate 5 devi fiecare, si fiecare echipa are 2-3 servicii, micro sau nu, in dezvoltare/mentenanta, cu 2-3 release-uri zilnic per echipa, e cam obligatoriu sa ai CI/CD si feature flags sau canary deployments, cu testare direct live. FF/Canary pentru QA .
Faceti un exercitiu de imaginatie si inlocuiti cele 2-3 release-uri zilnice de echipa cu clasicul 1-2 relsease-uri per sprint, tot de echipa, eventual fiecare release facut ca un bundle de 4-5 story-uri si taskuri si bug-fixes. 
Va zic eu din propria experienta ca mai degraba nu dormi noaptea in a doua varianta decat in prima. Poti sa ai si mama mediilor de Test/Stage/Preprod/Mirrorprod ca tot vor exista probleme. Asa ca de ce nu release in prod, activare feature pentru 0,1% din useri sau feature flag pentru QA si testare acolo.
2 Likes
depinde de proiect si de regulile de lucru.
dar eu sunt pentru test in productie (evident, in mod controlat, pentru a pastra minim impactul asupra mediului).
parerea mea poate e putin subiectiva pentru ca intrebarea asta mi-a adus aminte de vremurile cand uneoeri LUCRAM direct pe live 
1 Like
Exista foarte putine cazuri cand testarea ar trebui facuta in productie.
Un caz concret, este Apple Pay. Pentru Romania, nu exista mediu Sandbox. Fiecare banca a dezvoltat si testat in mediu de productie.
In acelasi timp, este si o problema de security si privacy. La productie nu ar trebui sa aiba access developerii sau testerii. Nu mai traim in vremurile in care modificam un fisier php si-i faceam upload prin FTP.
1 Like
Teoretic nu.
Practic, depinde…
Daca e vorba de ceva ce poate fi testat fara a fi intr-un mediu de productie, scriem cateva teste pentru flow-urile standard. Dar cand programezi o masina de tocat “frunze la caini” (joke) poti incropi un simulator, dar in realitate functionalitatea tot in productie o testezi.
Alt scenariu:
Pe acelasi proiect lucreaza 100-200 de oameni direct pe master, orice cod scris ajunge in spatele unor feature flag-uri si cand cineva vrea sa faca un deploy in productie ia ultima versiune care a trecut de pipeline, adica de testele automate.
Rezultatul este ca in productie o sa fie multe feature-uri incomplete sau netestate, dar se pot testa si lansa incremental in ‘productie’ fara sa afecteze utilizatorii.
Intr-o corporatie e foarte avantajos sa lucrezi in acest mod fiindca nu te mai blocheaza birocratia, adica poti oricand sa scoti un flag daca sunt probleme fara sa faci alt release.
1 Like
Trunk based development. I like it.
Offtopic: pregateste-te sa iti sara cativa in cap
1 Like
Depinde ce vrei sa testezi. Acum, daca trebuie, trebuie. Cand trebuie folosesc https://github.com/scientistproject/Scientist.net , are port-uri pentru mai multe limbaje.
Iti zic cum am testat eu niste refactorizari masive pe cod legacy “in productie”: am luat date anonimizate din productie pe masura ce se executau, alaturi de rezultate, le-am mutat pe niste cozi dupa care le-am procesat pe alte masini care rulau noua versiune, am pus loguri cu diferentele (si contextele in care apar ele).
Bonus: am identificat toate use case-urile, am populat data providerii din teste.