Dezvoltarea platformei unui magazin online

Sar de la “maturitatea inginereasca” la un subiect oarecum sensibil pentru peisajul local, romanesc, privind dezvoltarea software si magazinele online.

Si voi descrie cum vad eu procesul de dezvoltare software, indiferent ca vorbim de o companie mica, care decide sa colaboreze cu 1–2 programatori sau o companie matura.

Procesele, in mare, ar trebui sa fie la fel, pentru ca din punctul meu de vedere, nu inteleg cum poti face rabat la calitate sau sa accepti probleme si potentiale ingerente majore doar pentru ca esti la inceput. Dimpotriva, consider ca poate fi o reteta pentru dezastru, clientul isi face o opinie proasta si nu mai revine. Deci, degeaba investesti in campanii destepte de marketing, vizualuri si mesaje bune, dar crapa platforma sau te lovesti de probleme in checkout.

Avem doua subiecte:

• ca developer cum lucrez (tehnic)
• ca developer cum lucrez non-tehnic — gestionarea cerintelor, structurarea proiectului, etc (fie ca e o abordare waterfall sau agila)

Ca developer, unde lucrez?

Pe mediul local de lucru.

Cum ar trebui sa arate procesul pentru a incepe munca pe un proiect?

Primesc acces la un repository. Il clonez, execut o comanda si ar trebui sa am un mediu de lucru, local, functional.

Serviciile de care am nevoie, ar trebui sa le am disponibile prin docker (va vine sa credeti sau nu vagrant nu a murit, sunt agentii mari care inca folosesc setup pe vagrant) sau alternative. Daca eu sunt stapan pe ce fac si vreau optimizari, le pot instala si manual, dar, pentru fluxul de lucru ar trebui sa existe acest proces: clonare repo, rulez un script/o comanda => am mediul de dezvoltare gata.

De asemenea, pe masura ce se intampla lucruri si evolueaza arhictectura sau seed database, ar trebui sa am un proces de update.

Cine pregateste acest setup?

In proiectele in care am lucrat, oarecum era parte din primele taskuri. Tech Lead-ul impreuna cu primii dezvoltatori au acest task. Si e un proces de imbunatatire continua.

Cum dezvolt?

Scrii cod frumos, urmezi flow-ul stabilit (git flow sau altceva). Apoi ar trebui sa poti face push la un branch.

Poti avea o serie de pre-commit hooks (phpcs, rulat unit tests, alte verificari).

Dupa ce trimiti branch-ul ar trebui sa existe un pipeline — care sa execute acele verificari. In principiu sunt doua parti:

• verificarea codului (ex: phpmd, phpcs) / unit tests
• integration tests rulate la deschiderea unui MR (ideal ai un proces care genereaza un mediu)

In cazul unor platforme cu o complexitate mult mai mare, poti agrea sa generezi un mediu simplificat in care sa rulezi integration tests (cu asumarea unor limitari).

E totul in regula? Poti urma fluxul stabilit pentru a trimite catre QA (unde ar trebui sa existe un mediu si o suita de teste automate — functionale).

De acolo stage, validare din partea stakeholderilor (client). Si gata, e pregatit de productie, planificat cand o sa fie release.

Ce se intampla in realitate?

Unele companii, aplica fix fluxul de mai sus. Au infrastructura, resurse si urmeaza procesele. Pot avea 0 downtime deployments, red green deployments, etc.

Altele … variaza… de la a lucrat direct in productie, la 1 singur “stage” (in unele cazuri conectate la servicii / componente de productie) pe care lucreaza N developeri in acelasi timp, la tot felul de setup-uri inventate ca sa mearga (gen luat baza de date din productie, local, pe calculatorul developerului — cu toate datele clientilor, fara limitari sau procese care sa asigure respectarea legislatiei, nu mai zic de bune practici).

Ce se intampla daca nu urmez procesul descris mai sus?

Pai… “merge si asa”. Riscurile apar in general legat de partea de “compliance” cu legislatia o data. Apoi, impactul in fata clientilor (care pot sa primeasca emailuri de test, de exemplu). Stabilitatea platformei. Reputatia companiei. Lista poate continua.
Ca dezvoltator software, nu evoluezi.
Ca si Product Owner, nu ai vreodata siguranta ca ce modifici sau pui in productie e stabil si nu afecteaza platforma.
Ca Business Owner, crezi ca ai un TCO mic. Dar nu masori (si de multe ori nici nu stii sau nu ai cum sa afli), care e impactul real.

Checklist

• Ca developer nou, am un proces simplu si automatizat de a putea porni dezvoltarea pe calculatorul meu
• Am un flux de tipul gitflow prestabilit pe care il cunosc si il urmez cand fac modificari sau dezvoltari noi
• Am standarde de calitate referitor la cod (pe care le pot rula atat local cat si pe un CI)
• Am un proces de code review
• Am standarde de securitate (pe care le pot rula local sau in CI)
• Am pipelines care executa o serie de procese pentru asigurarea calitatii si securitatii codului scris/adaugat in proiect
• Nu pot trece mai departe in flux, daca nu sunt respectate standardele
• Am mecanisme de testare automata pentru asigurarea calitatii si integritatii
• Am un proces clar de QA
• Am procese automate pentru a face deployment pe QA, Stage, Productie
• Am procese clare legat de aprobari si notificarea stakeholderilor
• Am la dispozitie o platforma prin care pot sa vad metrici si loguri ale tuturor componentelor platformei, agregate intr-un singur loc
• In caz de probleme, pot face “rollback” in productie

Si mai exista decizii legate de “libertatea” acordata developerilor, de exemplu, oricine din echipa tehnica poate face deploy in productie. In fiecare punct, exista decizii si multe detalii ce se discuta si sa implementeaza, depinde aici de experienta fiecarui Tech Lead sau CTO, in ce directie doreste sa mearga.

Ce am expus mai sus, nu e un secret, e ceva ce multe agentii / echipe de dezvoltare folosesc, mai putin local, mai mult in piete mai mature.

Experienta voastra care e?