De la repository la producție: fluxul explicat

Repository-ul este sursa, nu serverul

Într-un flux modern, codul aplicației este păstrat într-un repository Git. Serverul nu este locul în care editezi manual fișierele. O versiune publică este rezultatul unui proces repetabil care pornește de la un commit identificabil.

Această separare oferă trei avantaje: poți reproduce build-ul, poți vedea exact ce s-a schimbat și poți reveni la o versiune anterioară fără să reconstruiești manual serverul.

Conectarea repository-ului

Clientul conectează propriul cont GitHub și alege repository-urile la care BeOnline poate avea acces. Pentru un repository privat, instalarea GitHub trebuie autorizată explicit pentru organizația și proiectul respectiv.

La crearea proiectului alegi:

• repository-ul și ramura de producție;
• metoda de build sau detectarea automată;
• portul pe care ascultă aplicația;
• comanda de pornire, dacă nu poate fi detectată;
• resursele de CPU și memorie;
• o adresă de verificare a sănătății aplicației.

Accesul poate fi revocat din GitHub. Pentru echipe, este util ca instalarea să aparțină organizației, nu contului personal al unui singur dezvoltator.

De la push la imagine

După un push, platforma citește commit-ul și pregătește un mediu izolat de build. Dependențele sunt instalate, aplicația este compilată și rezultatul este ambalat într-o imagine care poate rula identic pe infrastructura de deployment.

Un flux simplificat arată astfel:

git push
  -> preluare commit
  -> instalare dependențe
  -> build și teste
  -> creare imagine
  -> deployment
  -> health check
  -> trafic public

Logurile de build trebuie să indice comanda care a eșuat și codul de ieșire. Nu copia secretele în loguri și nu le include în repository.

Variabile și secrete pe medii

Configurația care diferă între preview și producție trebuie transmisă prin variabile de mediu. Exemple: adresa bazei de date, cheia unui furnizor sau URL-ul unui API.

• valorile secrete nu se salvează în Git;
• preview-ul și producția folosesc valori separate;
• schimbarea unui secret este auditată;
• accesul membrilor este limitat în funcție de rol;
• logurile nu afișează valoarea completă.

Fișierul .env local trebuie exclus din commit. Păstrează în repository doar un exemplu fără valori reale, de tipul .env.example.

Preview înainte de producție

Un preview oferă o adresă temporară pentru o ramură sau un pull request. Echipa poate verifica designul, fluxurile și integrarea înainte de promovarea versiunii.

Preview-ul nu trebuie conectat automat la baza de date de producție. Folosește date de test și chei separate. Dacă aplicația execută migrări, verifică compatibilitatea lor înainte de publicare.

O verificare utilă include:

1. build finalizat fără erori;
2. pagina de health check răspunde corect;
3. autentificarea și permisiunile funcționează;
4. operațiunile importante sunt testate;
5. erorile nu conțin secrete;
6. modificarea bazei de date este compatibilă cu revenirea.

Promovarea în producție

Deployment-ul de producție pornește o versiune nouă fără să elimine imediat versiunea stabilă. După pornire, platforma rulează verificarea de sănătate. Traficul este mutat doar dacă aplicația răspunde conform configurației.

Pentru proiecte importante, definește o ramură protejată și aprobări înainte de producție. Păstrează asocierea dintre deployment, commit și persoana care l-a inițiat.

Un domeniu personalizat este conectat după ce DNS-ul indică infrastructura corectă. Certificatul SSL poate fi emis automat după validarea domeniului.

Ce înseamnă un rollback

Rollback-ul redeployează o imagine anterioară cunoscută ca stabilă. Este rapid pentru cod, dar nu inversează automat modificările ireversibile din baza de date.

Înainte de o migrare importantă:

• creează o copie verificată a datelor;
• folosește schimbări compatibile cu ambele versiuni ale aplicației;
• separă eliminarea coloanelor de deployment-ul care încetează să le folosească;
• documentează pașii manuali de revenire.

Dacă health check-ul eșuează, deployment-ul nu trebuie prezentat ca reușit. Motivul trebuie afișat clar, iar versiunea stabilă trebuie să rămână disponibilă.

Vizibilitate după publicare

Un deployment nu se termină când containerul pornește. Urmărește consumul de CPU și memorie, latența, rata erorilor și restarturile. Corelează incidentele cu deployment-urile pentru a vedea dacă o problemă a apărut după o schimbare.

Alertele utile includ:

• build sau deployment eșuat;
• health check nereușit;
• aplicație indisponibilă;
• latență peste prag;
• consum apropiat de limita planului;
• certificat sau domeniu aproape de expirare.

Checklist pentru primul deployment

• Repository-ul și ramura sunt corecte.
• Accesul GitHub este limitat la proiectele necesare.
• Fișierele .env și secretele nu sunt în Git.
• Portul și health check-ul sunt configurate.
• Preview-ul folosește date separate.
• Build-ul și testele sunt reproductibile.
• Domeniul și SSL-ul sunt verificate.
• Există o versiune stabilă pentru rollback.
• Metricile și alertele sunt active.

Un flux bun reduce operațiunile manuale, dar păstrează fiecare decizie vizibilă. Scopul nu este doar să publici repede, ci să poți explica și recupera fiecare deployment.