Pentru versiunea bazată pe ramuri, trebuie să vorbim despre următoarea diagramă, care ilustrează perfect panorama procesului de management al configurației. În primul rând, această diagramă este scrisă pe baza modelului Git, dar, de fapt, Git și Subversion au descoperit conceptul de management al controlului versiunilor, însă Git face un salt calitativ înainte față de Subversion în managementul sucursalelor și performanța distribuită (însă acesta nu este subiectul acestui articol).
Înainte de a introduce principiul acestui graf, să vorbim despre două strategii diferite pentru controlul general al versiunilor: una este "backbone-ul pionier, ramură stabilă", iar cealaltă este "backbone-ul stabil, ramura pionier". După cum sugerează și numele, este versiunea stabilă (versiunea de producție), pe trunchi sau pe ramurală. În cazul echipelor de proiect tradiționale care folosesc VSS, este dificil de spus din ce mod aparține, în principal deoarece VSS nu are o strategie de management al sucursalei, așa că multe echipe de proiect stabilesc două biblioteci de versiuni (sau trei), corespunzătoare mediului de producție și mediului de dezvoltare, desigur, acesta fiind și un fel de management de sucursală deghizat. Totuși, dacă comori la Subversion sau Git ca instrument de control al versiunilor, majoritatea echipelor folosesc modul stable trunk, adică trunk-ul (truck sau master) corespunde unui mediu de producție stabil și etichetează diferite versiuni pentru a indica versiunea de producție. Personal, cred că modelul stabil de cod backbone ar trebui să fie soluția principală de gestionare a versiunilor codului în prezent. Imaginea de mai sus este modelul standard de management al "coloanei vertebrale stabile".
stăpân: Subversiunea corespunzătoare este truck。 Corespunzător versiunii de producție, este etichetat o dată la fiecare lansare.
Ramura de eliberare (cunoscută și ca ramura de integrare): Atâta timp cât producția este actualizată, trebuie mai întâi să fie integrată în ramura de lansare (ramura de integrare). Este oarecum similar cu ceea ce echipa de proiect numește în prezent conceptul de "pre-producție" și "mediu simulat".
ramura de dezvoltare (ramură de dezvoltare sau ramură de dezvoltare): Mediul cu care se confruntă mediul de dezvoltare.
Ramura caracteristicilor (ramură caracteristică): Unele funcții independente pot fi separate dintr-o ramură separată de dezvoltare. Acest lucru se face în principal pentru a face față faptului că unele funcționalități pot dura relativ mult timp pentru a fi actualizate, pentru a nu trage în jos lansarea și ramurile separate.
Ramura hotfixes (ramura de corectare a bug-urilor): Bug-ul aici este în principal un bug de producție.
După ce am introdus trunchiul și ramurile, trebuie să introduc direcția generării și fuziunilor acestor ramuri.
Master este versiunea de producție, iar trunchiul acceptă doar două ramuri pentru fuziune, una este ramura de eliberare (ramura de integrare) și cealaltă ramura hotfixes. Nicio altă ramură nu poate fi fuzionată într-o ramură de producție.
Ramura de lansare este creată inițial în același timp cu producția, ceea ce este exact la fel ca producția. El acceptă doar ramura de dezvoltare pentru a se uni cu ea. Cu alte cuvinte, el nu acceptă fuziuni directe din ramura de funcționalitate sau de la ramura de corecturi de bug-uri.
Ramura de dezvoltare, ramura de dezvoltare, la fel ca ramura de integrare, este aceeași cu mediul de producție la un anumit moment dat. Totuși, pe măsură ce dezvoltarea avansează, noi funcționalități vor continua să fie create pe ramura de dezvoltare. Teoria dezvoltatoare acceptă doar fuziunea a două ramuri, una este hotfix-ul și cealaltă este ramura de caracteristici.
Ramura de funcționalitate, începând de la un anumit punct (versiune) cu ramura de dezvoltare, ramura de funcționalitate va fi în cele din urmă fuzionată cu ramura de dezvoltare.
Să introducem pe scurt metoda controlului versiunilor sub forma unui scenariu
Să presupunem că o versiune de producție este împărțită în ramuri (dev, hotfixes, release), iar în acest moment, dev începe să dezvolte un total de zece funcții. Când 8 dintre cele 10 funcționalități au fost dezvoltate, echipa de testare a început să intervină pentru testarea internă, iar administratorul de configurare a implementat ramura de dezvoltare în mediul de dezvoltare pentru testare prin instrumente de integrare continuă (un subiect separat aici). Când verificarea de test a constatat că două dintre funcții erau complet inacceptabile și trebuiau refăcute, cum ar fi asigurarea simplă și returnarea cererii, două ramuri de funcționalități au fost separate de dev, corespunzătoare asigurării simple și rambursării cererii, iar pe ramura de dezvoltare, codul corespunzător a trebuit de asemenea revenit (operare manuală aici). Când echipa de testare constată că nu există nicio problemă cu testul ramurii de dezvoltare, acesta îndeplinește condițiile UAT, astfel că administratorul de configurare integrează ramura de dezvoltare cu ramura de lansare, apoi folosește instrumente de integrare continuă pentru a publica această ramură în mediul de pre-producție și a o preda utilizatorului pentru testare. Când verificarea utilizatorului găsește o problemă, dezvoltatorul modifică ramura de dezvoltare, apoi o combină cu ramura de lansare (aici, în imaginea originală, este modificată direct în ramura de lansare, cred că acest lucru nu este bine, recomand ca dezvoltatorul să se confrunte doar cu ramura de dezvoltare), când procesul de verificare a lansării descoperă brusc că există un bug grav în mediul de compilare care trebuie remediat imediat, atunci este modificat urgent pe ramura hotfixes și este lansat urgent după verificarea corectiunii. În același timp, ramura hotfixes este comasată cu dev (aici este în mare parte manuală, deoarece în acest moment versiunea de producție este deja foarte diferită de versiunea dev și adesea este imposibil să finalizezi uniunea automată), iar apoi dev este integrat în release. După o perioadă de timp, funcția de returnare a cererilor poate să nu mai fie necesară și trebuie anulată, astfel că ramura de funcționalitate de returnare a cererilor va fi ștearsă. O altă funcție este ușor de asigurat și a fost dezvoltată și integrată din nou în ramura de dezvoltare pentru a lansa următoarea versiune online.
Scenariul de mai sus include practic dezvoltarea de rutină, despachetarea, actualizările de urgență și alte scenarii în procesul zilnic de dezvoltare.
|
Postat pe 08.04.2018 10:25:39
|
|
|
|
