Crezi că este corect să combini construcția, testarea și publicarea imaginii într-un singur flux de lucru, precum și să adaugi pași pentru deployment în diferite medii?

Acest lucru nu este întotdeauna optim. Deși o astfel de abordare poate fi convenabilă pentru proiecte mici sau build-uri de test locale, combinarea tuturor etapelor într-un singur flux de lucru are dezavantaje:

• Reducerea flexibilității: Implementarea în medii diferite (dev, staging, producție) necesită parametri diferiți și adesea permisiuni de acces diferite. Combinarea complică gestionarea acestor diferențe.
• Dependența de mediu: Dacă implementarea într-unul dintre medii eșuează, întreaga construcție este considerată eșuată, chiar dacă crearea imaginii și testarea au fost reușite.
• Dificultatea de rollback: Reversarea implementării devine mai puțin trivială, deoarece trebuie să reveniți întregul workflow.
• Creșterea timpului de execuție: Întregul pipeline durează mai mult, ceea ce încetinește feedback-ul pentru dezvoltatori.
• Scalabilitate mai mică: Pe măsură ce proiectul crește și numărul de medii de implementare crește, acest workflow devine voluminos și dificil de gestionat.

O practică mai comună și mai flexibilă este divizarea acestor etape:

1. Pipeline de Build & Test: Se ocupă de compilarea codului, testare, crearea imaginii și plasarea acesteia în registrul de artefacte (de exemplu, Docker Registry, Nexus). Acest workflow pornește pentru fiecare commit sau pull request.
2. Pipeline-uri de Deployment: Workflow-uri separate pentru implementarea în fiecare mediu. Ele iau imaginea deja construită și testată din registrul de artefacte și o implementează în mediul țintă. Aceste workflow-uri pot fi inițiate manual, programat sau automat după finalizarea cu succes a etapei anterioare (de exemplu, implementare reușită în staging).

Aceasta permite:

• Obținerea unui feedback mai rapid despre calitatea codului (build & test).
• Implementarea independentă în diferite medii.
• Gestionarea mai flexibilă a parametrilor de implementare pentru fiecare mediu.
• Simplificarea procesului de rollback.

O excepție pot fi proiecte mici pet sau aplicații monolitice cu un proces simplu de implementare, unde costurile de divizare depășesc beneficiile. Cu toate acestea, în majoritatea mediilor corporative, divizarea workflow-ului reprezintă o practică recomandată.