Cum să stocați proiecte în depozitul de coduri în blog

Proiectul constă atât în codul său, cât și în bibliotecile terților. Bineînțeles, se pune întrebarea cum să păstreze acest bine. La această întrebare voi încerca să dau recomandări bazate pe propria mea experiență.

Dezvoltatorul trebuie să ajungă repede la lucru fără a-și ciocni capul, instalând o duzină de biblioteci.
Bibliotecile ar trebui să fie accesibile din diferite proiecte, evitând în același timp duplicarea codului în depozite.
Ar trebui să fie posibilă salvarea anumitor stări de proiect: versiuni noi, ansambluri de numere pentru testeri etc.

Înainte de a citi, recomand cu insistență citirea notei anterioare.

Vă recomandăm să vă creați propriul magazin pentru fiecare proiect. Acest lucru va face posibilă separarea clară a unui proiect de celălalt, dacă este necesar, acordarea drepturilor de a edita depozite specifice numai anumitor dezvoltatori, rezolvarea problemei cu arhivare. Bibliotecile, chiar terțe, ar trebui privite ca proiecte separate și stocate, de asemenea, în depozite separate. O excepție poate fi făcută numai pentru bibliotecile foarte mari, cum ar fi Qt sau Boost.

Subversiunea vă permite să stabiliți dependențe între proiecte, stabilind dependența proiectului de alte proiecte. Astfel, în același timp cu primirea proiectului din depozit, este posibil să se obțină tot codul necesar pentru muncă în mod automat, fără a complica viața prin instalarea mai multor biblioteci și monitorizarea relevanței acestora.

Dosare trunchi, etichete, ramuri

Adesea, în Subversion se utilizează structura de proiect a trei foldere: trunchi, etichete și ramuri. Pentru ce sunt?

trunchiul este dosarul pentru dezvoltare. Acesta conține întotdeauna cea mai recentă versiune a codului, disponibil dezvoltatorilor. Este extrem de important să păstrați întotdeauna codul într-o stare de colectare. Orice defalcare în asamblarea proiectului ar trebui corectată cât mai repede posibil, pentru a nu crea dificultăți pentru ceilalți dezvoltatori.
În etichete, există state de proiect pentru un anumit moment. De exemplu, mai aproape de lansare, dezvoltatorii încep să creeze, cu o anumită periodicitate de asamblare, un număr unic care este transmis testerilor. Starea proiectului în acest moment poate fi rezolvată în eticheta dosarului, atribuindu-i un nume cunoscut, de exemplu, build_723. Acest lucru va permite, în cazul unui defect lipsă în ansamblul dat și detectat în următoarea ansamblu, să analizați cauza problemei și să luați măsurile necesare pentru ao elimina. De asemenea, aici puteți marca versiunile lansate, de exemplu, 1.0.5. Astfel, după ce ați primit de la utilizatori o plângere despre un bug în orice versiune, puteți lua codul actualizat pentru această versiune, pentru a studia problema.
ramurile sunt sucursale temporare ale dezvoltatorilor. Ce înseamnă asta? Programatorul Vasya are sarcina de a adăuga anumite funcționalități. Pentru a nu bloca munca celorlalți membri ai echipei, acesta creează o copie a proiectului în sucursale / vasia_task_1234, lucrând în această ramură salvând periodic codul din depozit. După finalizarea sarcinii, se îmbină cu ramura principală de dezvoltare (portbagaj) și elimină ramura temporară. Sarcina este finalizată, în timp ce își poate fixa starea de lucru în linia de timp, fără a deranja munca altor dezvoltatori.

Lucrul cu ramurile și stabilirea stării proiectului în etichete vor fi descrise într-o altă notă.

Cum se numește versiunea?

Propun o metodă de numerotare a versiunilor compusă din trei cifre - majoră .minor .micro. în cazul în care:

major - un număr care indică versiunea produsului (numerele variate ale versiunii indică diferențe semnificative între produse);
expunerea minoră a produsului (numere diferite indică faptul că sub-elementele au funcționalități diferite);
micro - în limitele expunerii indică faptul că unele erori au fost corectate.

Când lansați o nouă versiune a remedierii numai pentru erori, numărul în poziția micro crește.
La lansarea versiunii cu funcționalitatea schimbată, aceasta crește incredibil și este resetată la micro.
Când lansați o nouă versiune a produsului semnificativ diferită de cea anterioară, creșterile majore, minore și micro sunt resetate la zero.

Exemplu de proiect

Luați în considerare un proiect simplu constând din codul de proiect real și două biblioteci (lib1, lib2). Structura a trei depozite:

sucursale
tag-uri
portbagaj

Proiectul în sine este proiectul nostru, care depinde de biblioteca terț lib1 versiunea 1.0 și de biblioteca dezvoltării proprii lib2, care este dezvoltată împreună cu proiectul în sine, astfel încât dependența va fi pe principala sa ramură de dezvoltare (portbagaj).

Instalați dependențe în Subversion

Fiți atenți la. - aceasta indică faptul că trebuie să afișați proprietățile setate pentru folder (unele proprietăți pot fi setate numai pentru anumite fișiere).

Pentru a edita și a adăuga proprietăți, există o comandă

Pentru a seta proprietatea svn: externals (desigur pentru întreg dosarul) în folderul cu ramura principală de dezvoltare (path_to local machine / project / trunk)

Pentru a șterge o proprietate, utilizați comanda

Arată așa. Acum, de fiecare dată când preluăm codul proiectului din depozit, codul pentru biblioteci se încarcă în același timp. Dacă s-au făcut modificări în biblioteci, acestea se vor actualiza automat. Astfel, după ce ați înregistrat dependențele proiectului, nu vă puteți gândi la biblioteci, acestea vor fi actualizate și descărcate automat, principala ramură de dezvoltare va conține foldere lib1 și lib2 cu biblioteci.

Următorul pas logic este colectarea automată a bibliotecilor necesare împreună cu proiectul, pe care îl voi discuta în curând cu exemplul instrumentului de automatizare a ansamblului CMake încrucișat.

Articole similare

Pagina anterioară