Cere o analiză

Acasă/Proiecte/Platformă B2B pentru laboratoare

Studiu de caz · În producție

Platformă B2B Tody:preluare și modernizare

O platformă de comenzi online pentru laboratoare, rămasă fără dezvoltator și fără cod sursă la zi. Am preluat serverele și aplicația, am reconstituit codul, am construit un mediu de test și un sistem prin care clientul aprobă și pornește singur fiecare modificare.

26,5 s → 5,3 ssalvarea unui newsletter cu calculul destinatarilormăsurat în producție
~3 min → ~16 sîncărcarea panoului de administraremăsurat în producție
0 diferențela migrarea bazei de date pe PostgreSQL 17oprire de ~30 min
129 paginitestate automat după reconstituirea coduluifără regresii
Situația

Rămasă fără dezvoltator

Tody furnizează scheme de control extern al calității și materiale pentru laboratoare medicale și vinde online către laboratoare, spitale și distribuitori din România și din străinătate. Platforma are peste 15.000 de produse active, aproximativ 50 de tipuri de clienți cu reguli de preț diferite și 6 valute.

Aplicația fusese făcută de mai mulți dezvoltatori care nu mai lucrau pentru client. Codul sursă existent nu mai corespundea cu ce rula în producție, iar unele pagini de administrare se încărcau în minute.

Înainte

  • cod sursă depășit față de producție
  • fără mediu de test funcțional
  • panou de administrare de ~3 minute
  • server și bază de date pe versiuni ieșite din suport
  • modificări pe producție fără control

După

  • cod sursă complet, compilat și verificat de noi
  • mediu de test cu date reale, fără mailuri către clienți
  • panou de administrare de ~16 secunde
  • Windows Server 2025 și PostgreSQL 17
  • fiecare modificare trece prin tichet, test și aprobare
Ce am construit

Șase piese care lucrează împreună

Aplicația clientului, plus uneltele prin care o întreținem fără riscuri.

Cod sursă reconstituit

Din versiunea aflată în funcțiune, compilat cu același compilator ca originalul și comparat componentă cu componentă cu producția.

Mediu de test cu date reale

Copie a producției în care mailurile nu pleacă la clienți, iar plățile cu cardul rulează în modul de test.

Aplicație de tichete

Clientul raportează, aprobă costul pe cerințe, testează și pornește singur urcarea pe site.

Urcare automată cu revenire

Fișierele și pașii de bază de date se aplică automat, cu verificarea fișierelor, copie înainte și buton de revenire.

Detectarea intervențiilor

Orice modificare de cod sau de bază de date făcută din afara echipei declanșează alertă pe telefon și pe e-mail.

Monitorizare și backup

Site-ul și autentificarea verificate la fiecare minut; copii de siguranță zilnice și săptămânale în cloud.

Rezultate

Ce s‑a schimbat, măsurat

Gri = înainte, portocaliu = după. La newsletter, o parte din câștig vine și din mutarea pe serverul nou.

Timpi de răspuns

Newsletter
26,5 s
după
5,3 s
Admin
~3 min
după
~16 s
Raport
60–100 s
după
2,3 s

Newsletter și panou de administrare: măsurat în producție. Raport de vânzări: măsurat pe mediul de test.

~30 minoprire la migrarea serverului și a bazei de date
2.617 → 161interogări la salvarea unui newsletter (test)
21 min, 0 erorirepararea completă a mapărilor EQAS (test)
496tabele și view-uri mutate pe PostgreSQL 17
30programe de fundal repornite după migrare
60 sintervalul de verificare a site-ului și a autentificării
Dificultăți rezolvate

Unde n‑a fost simplu

Cod sursă pierdut

Problema: sursa existentă nu mai corespundea cu aplicația din producție.

Soluția: am identificat exact fișierele modificate după amprentele din fișierele de depanare ale producției, le-am reconstituit, am refăcut integral o bibliotecă internă și am comparat rezultatul tip cu tip cu producția.

Pagini lente din cauze ascunse

Problema: panoul de administrare și newsletterul așteptau după mii de interogări mici și după cereri blocate una de alta.

Soluția: încărcarea datelor în grupuri și cereri în paralel, fără să schimbăm logica aplicației.

Migrare cu oprire minimă

Problema: sute de GB de date de mutat pe un server nou.

Soluția: discul de date a fost mutat direct pe mașina nouă, iar baza a fost copiată în paralel și verificată prin numărători pe tabele.

Cum ajunge o modificare pe site

De la cerere la producție, în 5 pași

Tichetclientul descrie cererea și urgența
Cost aprobatpe cerințe, cu aprobare prin e-mail
Testmodificarea se face și se verifică pe mediul de test
Acceptareclientul testează pe mediul de test
Urcareautomată, cu verificarea fișierelor și buton de revenire

Aplicație

ASP.NET MVCC#NHibernatejQuery

Date și servere

PostgreSQL 17Windows Server 2025Hyper-VPowerShell

Unelte proprii

PythonDockerPlaywrightUptime Kumantfy
Rolul lui Claude

Cum am lucrat cu Claude la Tody

Fiecare cerere a clientului devine un tichet, iar fiecare tichet se lucrează într-o conversație separată cu Claude.

Ce a făcut Claude

  • analiza codului și a bazei de date
  • reconstituirea codului sursă și compararea cu producția
  • modificările, scripturile și testele pe mediul de test
  • pachetul de urcare, cu pașii de revenire
  • documentația fiecărui tichet

Ce am făcut noi

  • deciziile: ce se face, când și în ce variantă
  • verificarea finală și măsurătorile în producție
  • serverele și rețeaua, accesele
  • relația cu clientul

Ce face clientul

  • aprobă costul fiecărei cerințe
  • testează modificarea pe mediul de test
  • pornește singur urcarea pe site

Nimic nu a ajuns în producție fără test, pași de revenire și confirmarea unui om. Cum lucrăm cu Claude în toate proiectele →

Ai o aplicație rămasă fără dezvoltator?

Spune-ne ce rulează și ce nu mai merge. Începem cu o analiză, nu cu o ofertă.

Descrie-ne aplicația →