eu as vrea sa fie voie sa rescriu istoria de commituri, dar e greu de schimbat mentalitati intr-un loc in care sunt codebaseuri in clearcase de ex
Am inteles si sunt perfect de acord.
Dar eu am 2 perspective:
-
Prima pespectiva: am lucrat pana in 2015 la firme mici. Sau cu departament IT mic. Stiu, perioada aia poate fi considerata deja epoca de piatra dar pe vremea aia mai greu cu unit testing si ci/cd mai ales pe proiecte cu limbaje precum php. Intr-adevar, eu am avut noroc de colegi buni care faceau code reviews cu simtul raspunderii. Dar standardul vremii era altul.
-
A doua perspectiva: tin saptamanal cel putin 1 interviu tehnic, Am tinut peste 200 pana azi. Nu ma laud pentru ca sunt sigur ca altii poate au 1000 la activ pe forumul asta. Doar vreau sa creez contextul. Si anume, cam 1 din 2 candidati care vin la interviu si provin din companii mici stiu unit-testing doar la nivel teoretic. CI/CD vezi doar la firme mari sau firme mici cu proiecte serioase sau clienti demanding.
Da, corect dar nu ma refer la asta. Ma refer la nr total de useri pe care ii are produsul tau. Alte pretentii sunt la 1000 de useri pe zi vs 10 milioane de useri pe zi.
2 Likes
Tocmai din perspectivele acestea ar trebui sa aleaga un proiect/o firma unde poate invata bine unit testing, ci/cd, trunk-based development si cum se lucreaza cu code review. Adica in mod ideal cauta un client demanding care cere toate astea in loc de o firma mica unde se face codare de site-uri de prezentare sau in cel mai bun caz MVP-uri. In viitor cand ajunge la o firma care vrea sa ii dea un salariu mare pe experienta sa o sa fie unul din 1/2 care va sti cum arata un proiect sanatos unde clientul si-a permis tot ce-i mai bun si se poate mandri ca n-a livrat un feature fara sa aiba coverage de peste N%.
Sunt destui clienti care isi permit si vor tot ce-i mai bun dar nu gasesc oameni.
1 Like
OT message.
Separarea asta dev/ops/QA/program manager/etc nu-mi arata bine si nu e chiar moderna.
In principiu vrei sa faci release cat mai repede iti permite categoria de proiect pe care o ai. In webdev ar trebui sa fie “instant” (ca pe vremuri cu scp project/ [email protected]/www), in mobile dev cat permite Google/Apple, pe autoturisme la viteza de distributie a service-urilor, etc.
Toata infrastructura de TDD/CI/CD etc. e intr-un fel un mod de a ajunge la viteza maxima a categoriei, si a asigura calitatea si siguranta unui release. Dintr-un PDV-uri tot IoT si connected cars tech vine sa aduca bunatatile din “webdev” in zonele astea unde update-urile se faceau odata per deceniu …
Sa blochezi un release de “serviciu” sau “webapp” de un QA/PM/PMM/etc merge mult importiva ideii asteia.
Mai degraba si mai ales pe “backend”, devs ar trebui sa fie ei in control al unui release - fie via CD, fie cu vre-un pas separat de release. Calitatea si stabilitatea se mentine cu testare, monitorizare si alertare, gradual/red-blue releases/feature flags, AB-tests, etc.
Ditto, ideal ar trebui sa poti sa faci un release oricand. Release freezes sunt un anti-pattern.
Also – per feature environments 
OK, nu multi il au, dar daca e infrastructura facuta de la inceput e super.
2 Likes
Niciunul nu blocheaza release-ul ci creeaza un proces in care exista raspundere ca sa se evite situatiile cand face release cineva in care n-ai incredere ca respecta fiecare cerinta. Un dev automat are un conflict de interese, el vrea sa livreze cat mai rapid si sa sara etape. Un PM are interesul sa vada ca ceea ce se da la clienti e functional si sa faca rollback daca ceva nu e in ordine. Un QA are interesul de a mentine calitatea si e normal sa blocheze un release daca sunt probleme, in mod ideal tot ce trebuie testat la release e automatizat.
La baza de date nu ai feature flags, ai script-uri de migrari care trebuie rulate automat, nu da orice dev comenzi de sql pe prod ca poate iti ia cateva ore sa restaurezi un backup de sute de Gb. Eventual fiecare migrare are efecte asupra performantei, in special daca se schimba tabele in care lipsesc indecsi si ar afecta milioane de randuri. Daca vine o echipa incepatoare si da o comanda SQL fara sa stie cum va afecta performanta iti poate afecta uptime-ul sau platesti cateva mii de dolari pentru release daca ai autoscaling.
Cu feature flags nu inseamna ca poti face release la tot, nu orice se poate pune in spate la feature flags.
1 Like
Disagree cu respect. Nu zic că nu e așa în industrie în unele/multe locuri. Dar e anti-pattern clar. Toată lumea din echipa e în aceiași barca. Interesul dev-ului nu este să pushuiasca cod aiurea și mult în prod, ci să aibă un produs/felie de produs “bună”. La fel că al PM-ului sau QA-ului.
Daca ai o echipa matura, cu așteptări mari, cu responsabilitate și autonomie sa livreze, e mai constructiv decât dacă ai low-trust, piedici, procese, și gatekeepers.
IMO odată ce sunt setate chestiile astea, daca cineva nu le îndeplinește e mai mult caz de acționare locală: training, coaching, reviews mai cu atenție. Daca omul totuși nu se îndreaptă și produce mai mult damage decât beneficiu, poate nu-i un fit bun ptr echipa și companie și e mai bine sa ne despărțim.
Wrt migrări am văzut și situații cu “db team care executa migrările” și cu CI step care le face automat. Pentru baze destul de mari, nu de jucarie. It can work ofc, dar din nou când e ownership si trust. Daca omul considera că DB-ul e problema echipei de DBAs sau SREs într-adevăr apar probleme de genul. Daca insa e a lui (la modul DevOps) atunci are tot interesul să fie totul în regula.
2 Likes
Stiti ca sunt studii facute care fac legatura directa intre high performing orgs si rapiditatea cu care ajunge software-ul in productie. E scrisa si o carte pe tema asta, Accelerate: Building and Scaling High-Performing Technology Organizations, recomand cu caldura.
Si mie mi se parea OK si best practice sa ai “promote to qa” button, release by Release Manager, no deploy fridays, etc. Acum lucrez pe principiul “you build it you run it” si parca nu am mai fost frustrat demult.
Oh da, nici macar rol de QA nu mai avem in echipa 
Sorry dar consider ca din moment ce ai niste automatizari in place, feature flags, canary deployments, trunk-based development(asta nu il avem inca), one-click deploy/rollback si testare de acceptanta bunicica…QA inceteaza a mai fii un rol in echipa ta si devine o practica.
5 Likes
Aș aprecia dacă ai da share unor resurse OK pe baza cărora v-ați organizat voi flow-ul, aș vrea să implementez ceva de genul acesta și m-ar ajuta niște documentație „peer-reviewed”. 
Heavily inspired de catre acest talk https://www.youtube.com/watch?v=vGCowJY5QCQ (Sorry, only spanish, dar daca vrei pot face un rezumat/traduce slide-urile undeva next week. Let me know)
Apoi o gramada discutii si observatii facute pe organizatii care chiar consideram noi ca performeaza in tech. Gasesti multe discutii si pe Blind dar na…nu sunt chiar “oficiale”.
In principiu, noi am observat urmatoarele trenduri in “big tech”,
- rolurile de QA/SDET sunt pe cale de disparitie, trend deja inceput de cativa ani. OK, testarea nu dispare ca disciplina. Dispare insa figura unui QA dedicat. Discutia este mare aici si pot iesi scantei, mai ales ca vorbim de jobul unor oameni. Dar solutii exista daca se doreste.
- Trunk-based development cu Feature Flags devine standard cam peste tot
- Scrum scade in popularitate. Creste in popularitate kanban. Taskurile se livreaza fara estimari mai nou(no-estimates movement).
Ideea e sa livrezi cat mai repede munca in productie. Sa observi ce se intampla si sa actionezi bazandu-te pe date(cat se foloseste x feature? de cati useri? daca nu e folosit suficient pe web, mai are sens sa dezvoltam si pentru ios/android?).
6 Likes
Nu ai neaparat nevoie de QA in echipa, poti avea QA pe proiect/companie si cand e necesar fac ei exploratory testing/regression.
Problema e ca nici cu automatizare si nici cu testare manuala nu poti garanta 100% ca ai testat tot sau ca testele sunt mereu de incredere. Iti faci un plan de test prin care incerci sa acoperi cat mai multe, automatizezi in mare test case-urile la functionalitatile principale (ca daca ai automatiza fiecare edge case ar dura mult si cresc sansele de teste flaky care pot bloca release-ul/build-ul).
Sunt doua motive pentru care asta functioneaza:
- Daca se gaseste un bug in productie automat trebuie sa faci post-mortem/sa colectezi tot ce stii despre incident si sa tii un meeting despre el. Ceea ce te obliga ca dev sa ai grija sa nu prea livrezi cu bug-uri ca daca se gaseste in prod arata urat si ai si mai multa munca de birou, meeting-uri si vorbit cu oameni random. Daca la fiecare feature de care raspunzi se gasesc constant bug-uri in prod inseamna ca nu esti un dev destul de bun, ca e o problema cu echipa sau modul de lucru.
- Se angajeaza programatori cu simt de raspundere carora le pasa ce livreaza si vor sa inteleaga ce vrea clientul, nu doar codeaza o aplicatie.
3 Likes
Am observat si eu un fenomen asemanator, in momentul in care se “compartimentalizeaza” anumite functii, de exemplu separare qa de development, cumva se strecoara in mintea developerului ideea ca e oricum cineva down the line care o sa-i verifice codul si se muta responsabilitatea afectand si modul cum va aborda taskurile
.
Daca departamentul de QA a acceptat un feature atunci inseamna ca e ok si e vina lor ca nu au testat cum trebuie si cand apar problemele totul devine un blaming game cu discutii nesfarsite despre cine a gresit care schimba in timp relatia dintre dev si QA care devine una de opozitie si nu de colaborare/parteneriat.
5 Likes