Gestionarea versiunilor este un proces important în orice proiect de development. Acesta asigură că modificările aduse produsului sunt urmărite și documentate, ceea ce ajută la prevenirea pierderii datelor și la facilitarea colaborării între echipe. 

Beneficiile utilizării unei bune practici de gestionare a versiunilor, includ:  

• prevenirea pierderii datelor prin urmărirea modificărilor aduse produsului; 
• facilitarea colaborării între echipe cum ar fi testarea și operațiunile; 
• îmbunătățirea calității produsului prin identificarea și remedierea problemelor mai devreme în proces. 

Un alt aspect important este demonstrarea lucrului efectuat la un anumit produs, îndeosebi produsele voluminoase, ceea ce ajută la demonstrarea efortului depus și valorii echipei într-un anumit proiect. 

Gestionarea versiunilor este un aspect esențial al dezvoltării software, care implică monitorizarea și controlul modificărilor efectuate asupra codului sursă, documentației sau a altor artefacte. Există două metode principale de gestionare a versiunilor: gestionarea manuală și cea automată. 

Gestionarea Manuală a Versiunilor 

Gestionarea manuală a versiunilor implică monitorizarea schimbărilor și actualizarea lor manuală în fișierului CHANGELOG.md. În acest proces, programatorii trebuie să-și țină evidența modificărilor și să le aplice manual la fiecare release sau conform criteriilor declanșatori. 

Gestionarea Automată a Versiunilor 

Automatizarea versiunilor implică configurarea proiectului în așa mod ca la fiecare creare de tag să se genereze automat lista cu schimbările de la tag-ul precedent până la cel creat și să fie adăugate în CHANGELOG.md automat. Cel mai des aceasta automatizare este bazată pe semantica commit-urilor, prin urmare contează ca commit-urile să urmeze o convenția Conventional Commits.

Criterii de declanșare 

Atât pentru gestionarea automată cât și pentru cea manuală este nevoie să se știe când anume se creează o versiune nouă, ce anume trebuie să se întâmple, mai jos sunt enumerate o lista de declanșatoare: 

1. Sfârșit de Sprint sau Milestone – Acest criteriu se referă la finalizarea unui sprint sau a unui milestone în cadrul ciclului de dezvoltare al aplicației software. Un sprint este o perioadă de timp (de obicei 2 săptămâni) în care echipele de dezvoltare lucrează la seturi specifice de sarcini sau funcționalități. Un milestone marchează un punct de referință semnificativ în progresul proiectului. 
2. Declanșator – Atunci când toate sarcinile planificate pentru un sprint sau un milestone sunt finalizate și revizuite în mod satisfăcător, se declanșează procesul de release. 
3. Creare de Release sau Build – Acest criteriu se referă la momentul în care o versiune funcțională a aplicației software este pregătită pentru distribuire către utilizatori sau pentru a fi testată în medii de testare. 
4. Declanșator – Odată ce toate modificările de cod relevante au fost încorporate într-o versiune coerentă și testabilă a aplicației, se inițiază procesul de creare a release-ului sau a build-ului. 
5. Sfârșitul orelor planificate de mentenanță a proiectului – Acest criteriu indică momentul în care orele planificate de mentenanța a proiectului a ajuns la sfârșit. Mentenanța proiectului poate include activități precum remedierea bug-urilor, optimizarea performanței, adăugarea de funcțional nou și alte actualiză necesare. 
6. Declanșator – Atunci când orele de mentenanță planificate expiră și toate activitățile de întreținere necesare au fost completate sau programate pentru o versiune viitoare, se poate declanșa un nou release. 
7. Un anumit funcțional fără o perioadă definită – Acest criteriu se referă la implementarea unui anumit set de funcționalități care sunt dezvoltate și sunt disponibile pentru lansare odată ce sunt gata. La fel aici sunt alte situații neprevăzute sau urgente precum ar fi un hotfix pe mediul de producție care nu implică mult timp pentru soluționare. 
8. Declanșator – Atunci când dezvoltatorii finalizează implementarea și testarea unei funcționalități noi, unui hotfix, sau a unei caracteristici, aceasta poate fi integrată în următorul release al aplicației fără a fi legată de un sprint sau un milestone specific. 

Tipuri de versionare 

Semantic Versioning (SemVer) și Calendar Versioning (CalVer) sunt două abordări diferite pentru versionarea software-ului, fiecare cu avantajele și situațiile în care poate fi preferată. Mai jos este o descriere a fiecărei abordări și situațiile în care fiecare ar putea fi utilizată: 

• Semantic Versioning (SemVer) Semantic Versioning 2.0.0 | Semantic Versioning (semver.org): Semantic Versioning este o metodă de versionare care utilizează un format major.minor.patch pentru a indica schimbările într-o aplicație software. În mod tradițional, aceste componente sunt interpretate astfel: 
• Major: O creștere semnificativă a funcționalităților sau schimbărilor care nu sunt retrocompatibile cu versiunile anterioare. 
• Minor: Adăugarea de funcționalități noi, compatibile cu versiunile anterioare. 
• Patch: Corectarea bug-urilor sau realizarea de îmbunătățiri minore, fără a adăuga funcționalități noi sau a schimba API-ul public. 

Situații când ar trebui utilizată Semantic Versioning: 

• Aplicațiile sau bibliotecile care doresc să ofere o claritate și transparență cu privire la schimbările din fiecare versiune. 
• Dezvoltarea de biblioteci sau framework-uri care trebuie să fie compatibile cu versiunile anterioare și să ofere informații clare despre modificările aduse. 
• Calendar Versioning (CalVer) Calendar Versioning — CalVer: Calendar Versioning este o abordare de versionare care se bazează pe calendar și folosește data pentru a indica versiunile. În CalVer, versiunile sunt formatate în funcție de data lansării sau a altor evenimente calendaristice relevante. Există mai multe variații de CalVer, unele utilizând anul și luna (de exemplu, YYYY.MM), altele incluzând și alte informații calendaristice, cum ar fi numărul săptămânii sau chiar ziua calendaristică. Situații când ar trebui utilizată Calendar Versioning:  
• Proiectele care doresc să indice clar ordinea lansărilor și să ofere o referință ușor de înțeles pentru utilizatori. 
• Aplicațiile sau serviciile care nu necesită o structură specifică de versionare și preferă o abordare mai simplă și mai intuitivă, precum proiectele în continuă dezvoltare sau fără un API public. 

Crearea versiunii manuale 

O versiune nouă este creată conform criteriilor declanșatoare sau la prima inițiere a proiectului și urma următorii pași: 

1. Inițierea Changelog-ului – Changelog-urile reprezintă o parte esențială a procesului de dezvoltare și comunicare în cadrul proiectelor. Ele oferă o perspectivă asupra modificărilor aduse în fiecare versiune a aplicației și sunt destinate nu doar dezvoltatorilor, ci și altor stakeholders. 

• Changelog-urile trebuie să fie inițiate după primul release pe mediu de producție. 
• Ele nu sunt destinate exclusiv dezvoltatorilor, ci și altor părți interesate (stakeholders). Prin urmare, limbajul utilizat ar trebui să fie accesibil și descriptiv, ușor de înțeles pentru toate categoriile de utilizatori. 
• Changelog-urile nu coincid întotdeauna cu mesajele din commit-uri, deoarece un feature sau un bugfix poate implica mai multe commit-uri, prin urmare ar trebui indicat manual schimbările sau de schimbat mesajul commit-ului din merge-request. 

2. Responsabilitățile pentru completarea Changelog-ului

• Persoana care inițiază pull/merge request-ul este responsabilă pentru completarea changelog-ului. 
• Reviewer-ul are rolul de a verifica și asigura completarea corectă a changelog-ului. Acest proces reduce timpul necesar responsabilului de release-uri pentru a completa changelog-ul. 

3. Conformitate cu tipul de versionare SemVer sau CalVer 

• Trebuie să se respecte standardul SemVer sau CalVer în dependență de proiect și adăugarea schimbărilor conform. 
• Să se ia în calcul timpul de aplicație web/mobile și unde va fi publicată această aplicație pentru că AppStore și PlayMarket acceptă aplicațiile după un anumit standart, alt exemplu este npm registry care acceptă doar SemVer. 

4. Fluxul de lucru recomandat – Keep a Changelog 

• Se creează un fișier CHANGELOG.md în directorul principal al proiectului, urmând formatul specificat în link. 
• Se adaugă un nou paragraf cu titlul ## [Unreleased], urmat de alte subparagrafe: ### Added, ### Fixed, ### Changed, ### Removed conform convenție de changelog. 
• În momentul realizării unui release, dezvoltatorul responsabil pentru proiect adună toate modificările incluse în acel release și le completează în subparagrafele corespunzătoare sau deja sunt adăugate din fiecare merge/pull request și este nevoie doar de o verificare. 
• Ulterior, titlul ## [Unreleased] este modificat cu numărul sau data release-ului, de exemplu: ## [0.0.5] – 2014-08-09. 
• La necesitate și în dependență de proiect se creează tag cu versiunea specifică. 

Crearea versiunii automate 

Pentru a crea un flux de lucru pentru generarea automată a changelog-urilor în cazul creării versiunilor automate, este important să urmăm următorii pași: 

1. Automatizarea Generării Changelog-ului: 

• Utilizați instrumente și scripturi automate pentru a genera changelog-uri pe baza commit-urilor, PR/MR-urilor sau tag-urilor asociate cu versiunile. 

• Alegeți un instrumentelor de automatizare, cum ar fi Semantic Release, Conventional Commits, auto-changelog, git-cliff sau orice alt instrument care se potrivește cu nevoile și preferințele proiectului. 
• Procesul poate fi automatizat direct în proiect prin diferite scripturi și utilități ca git hooks sau poate fi automatizat în CI/CD pipeline. 

2. Conformitatea cu convenția commit-urilor – Asigurarea că membrii echipei urmează convențiile de scriere a commit-urilor, cum ar fi Conventional Commits, pentru a permite generarea automată a changelog-urilor pe baza commit-urilor. 

• Configurarea Automatizării – Configurarea instrumentul de automatizare (git hooks, pre-commit, MR/PR, CI/CD pipeline) pentru a monitoriza branch-urile relevante (de exemplu, branch-ul de producție), creare de tag-uri pentru a detecta momentele de realizare a versiunilor. 

• Generarea Changelog-ului automat – Odată ce o nouă versiune este realizată (de exemplu, prin crearea unui tag de versiune), instrumentul de automatizare ar trebui să genereze automat changelog-ul pe baza commit-urilor din acea versiune. Changelog-ul generat ar trebui să includă modificările aduse de fiecare commit într-o manieră coerentă și ușor de înțeles. 

• Publicarea Changelog-ului – Changelog-ul generat automat ar trebui să fie publicat într-un loc accesibil pentru membrii echipei și pentru alți utilizatori interesați, cum ar fi documentația proiectului, fișa proiectului sau fișierul CHANGELOG.md din repository-ul proiectului. 

• Verificarea și Revizuirea Changelog-ului – Este recomandabil ca membrii echipei să verifice și să revizuiască changelog-ul generat automat pentru a se asigura că este complet și precis înainte de lansarea versiunii. 

• Îmbunătățirea și Adaptarea Fluxului de Lucru – Revizuirea și adaptarea fluxul de lucru în funcție de feedback-ul echipei și de schimbările în cerințele proiectului pentru a îmbunătăți procesul de generare a changelog-urilor. 

 ~ Marcel Lefter