Anatomia unui deploy

Lectură estimată: 4 minute

Estimare pentru text, la un ritm de 180 de cuvinte pe minut. Timpul pentru analizarea codului, exerciții și proiecte se adaugă separat și depinde de ritmul tău.

Problema pe care o vei rezolva: Două release-uri și un rollback verificat

Release A afișează versiunea A; B afișează B și adaugă un câmp opțional. Datele create de A trebuie să rămână citibile. Health check-ul include o citire din baza de test.

Rezultatul urmărit

Pregătește buildul, migrarea compatibilă și comutarea release-ului. Simulează eșecul health check-ului și revino la A fără să ștergi date.

Cum recunoști o soluție corectă

Rollbackul codului readuce A, iar datele existente rămân valide. Migrarea nu elimină câmpuri necesare vechiului release. Workers și cache-urile sunt tratate explicit în runbook.

Parcurge lecțiile în ordine și păstrează exercițiile în registrul descărcabil. Ultima lecție include atelierul de 40 de minute în care combini conceptele și testezi o variație a situației inițiale. Exemplele comerciale sunt fictive; nu reprezintă rezultate ale unor clienți.

Deploy înseamnă să pui codul nou în producție fără să strici nimic. Un deploy bun are trei calități: e repetabil (aceiași pași de fiecare dată), e rapid (secunde, nu ore), și e reversibil (poți reveni imediat dacă ceva e greșit). Lecția asta e harta pașilor; restul cursului intră în fiecare.

Pașii unui deploy tipic

Aduci codul nou pe server (git pull sau un artefact construit).
Instalezi dependențele (composer install, npm ci).
Construiești asset-urile (npm run build).
Rulezi migrațiile de bază de date.
Golești și reconstruiești cache-urile.
Repornești worker-ii de coadă și, dacă e cazul, PHP-FPM.

Automatizează totul

Un deploy manual = pași uitați. Pune toți pașii într-un script (`deploy.sh`) sau într-un pipeline (GitHub Actions, GitLab CI, Forge, Deployer). Rulezi o comandă, nu zece.

Ce merge prost de obicei

Cod care folosește o coloană/tabel care nu există încă (ordine greșită).
Cache vechi servit după deploy (config, rute, vederi).
Worker-i de coadă care rulează cod vechi (nu i-ai repornit).
Permisiuni pe `storage/` pierdute după un `git pull`.

Medii

local (laptopul tău) → staging (o copie a producției, pentru testat deploy-ul și migrațiile) → production. Ideal ai staging. Minim: testezi migrațiile pe o copie a datelor de producție înainte.

Exercițiu

Scrie pe hârtie secvența exactă de pași pentru a face deploy la aplicația ta (sau la un proiect Laravel exemplu). Marchează care pași sunt periculoși (migrări, ștergeri) și care trebuie făcuți în ce ordine față de aducerea codului.

Greșeli frecvente

Deploy manual, pas cu pas, din memorie.
Rulezi migrațiile înainte să aduci codul care le folosește.
Nu reconstruiești cache-ul și producția servește configurație veche.
Faci deploy vineri seara și pleci.

De reținut

Deploy bun = repetabil + rapid + reversibil.
Pași: cod → dependențe → build → migrări → cache → workeri.
Automatizează într-un script sau pipeline.
Staging (sau măcar test pe copie) înainte de producție.

Pe scurt

Un deploy e o secvență fixă de pași. Automatizeaz-o, respectă ordinea (cod înainte de migrări), reconstruiește cache-ul, repornește workerii.

Manifestul unei versiuni publicabile

Un deploy trebuie să identifice exact codul, schema și asseturile care merg împreună. Nu publica un director de lucru cu modificări neinventariate. Construiește un manifest și verifică înainte dependențele, testele și compatibilitatea migrărilor. Schimbarea legăturii către versiunea activă este doar un pas; workerii, cache-urile și fișierele persistente trebuie incluse în plan. Un răspuns HTTP bun nu dovedește că joburile rulează corect.

Exemplu de lucru

Manifest: commit/identificator versiune; PHP; dependențe lock; hash asseturi; migrații; variabile noi; verificări; versiune de revenire.
Ordine: pregătire → verificare → backup → migrare compatibilă → activare → cache/worker → verificare publică → monitorizare.
Persistente: uploaduri, sesiuni și date, separate de codul versiunii.

Interpretarea rezultatului

Versiunea anterioară nu trebuie suprascrisă înainte de confirmarea celei noi. Un director de release trebuie să poată fi asociat manifestului, fără a include secrete în raport. Nu introduce o migrare incompatibilă într-un deploy care pretinde revenire instantanee.

Exercițiu de consolidare

Completează manifestul pentru o schimbare care adaugă un câmp opțional și o foaie CSS nouă.

Aplicație practică

Sarcina

Scrie ordinea unui deploy pentru o aplicație demonstrativă.

Rezolvare orientativă și verificare

Verificare, build, backup, publicare, migrare compatibilă, health check și monitorizare formează un flux controlabil.

Greșeală de evitat

Succesul copiei fișierelor nu este succesul aplicației.

Documentație și surse

Documentația Laravel 11 — versiunea aplicației demonstrative — Laravel
Ubuntu Server documentation — Canonical