Upravljanje konfiguracijom softvera

Sadržaj

1. Sistemi za kontrolu verzija

1.1. Sistemi za kontrolu verzija

• Sistem za kontrolu verzija (eng. Version Control System - VCS) upravlja promenama nad digitalnim stavkama konfiguracije (Configuration Item - CI).
• Daje uvid u sve promene koje su učinjene nad artifaktima koji su predmet kontrole verzija sa svim relevantnim metapodacima kao što su:
  • Ko je načinio promenu?
  • Kada je promena učinjena?
  • Šta je tom prilikom promenjeno i na koji način?
  • Nad kojom verzijom je promena učinjena, odnosno koje promene su prethodile?
  • …
• Omogućava vraćanje na verziju iz prošlosti i kreiranje alternativnih tokova razvoja/varijanti.

2. Osnovne definicije

2.1. Verzija

• Verzija predstavlja stanje evoluirajuće stavke konfiguracije.
• Shvatanje verzije u današnjem kontekstu popularnih VCS-ova sa snapshot modelom istorije jeste da verzija predstavlja stanje projekta u određenom trenutku u istoriji, tj. verzija je snapshot.
• Svaka verzija u VCS-u mora biti identifikovana na jednoznačan način.

2.2. Identifikator verzije

Identifikator verzije (IV) je objekat koji zadovoljava sledeća pravila:

• jedinstvenost – ne sme postojati dva istorijska objekta (verzije) unutar istog repozitorijuma sa istim identifikatorom,
• jednostavnost – IV bi, ako je moguće, trebao biti kratak i jednostavan za upotrebu (npr. iz korisničkog interfejsa),
• stabilnost – IV ne sme da se menja u vremenu i između različitih kopija istog repozitorijuma kod DVCS-ova.

2.3. Identifikator verzije - dodatne napomene

• Kod centralizovanih sistema IV može biti numerička oznaka koja se uvećava sa svakom verzijom dok kod distribuiranih, zbog prirode arhitekture, moraju se koristiti drugi algoritmi.
• Najčešći algoritmi danas u upotrebi kod DVCS-ova su bazirani na kriptografskim jednosmernim heš funkcijama (npr. SHA1) nad sadržajem promene.
• S obzirom da vrednost heša nije pogodna za ručni unos neki DVCS-ovi pribegavaju uvođenju dodatnih jednostavnih oznaka verzija koje su lokalne prirode i automatski se mapiraju na globalne IV-ove. Na taj način obezbeđuje se jednostavnost upotrebe uz očuvanje globalne jedinstvenosti koju nudi IV baziran na hešu.

2.4. Promena (Change)

• Definiše se najčešće kao niz operacija koje prevode stavku konfiguracije iz jedne verzije u drugu.
• Posmatra se na nivou jedne stavke konfiguracije (u kontekstu tekućih VCS-ova to je fajl).
• Skup promena (eng. changeset - CS ) predstavlja više logički povezanih promena koje prevode stanje projekta iz jedne verzije u drugu.
• Promena i skup promena se često nazivaju i delta ili diff (prema jednom od popularnijih algoritama i alata za određivanje razlike dva fajla).

2.5. Radni prostor (Workspace) ili radna kopija (Working Copy)

• Privatni prostor u kojem programer vrši izmene.
• Najčešće skup foldera i fajlova na lokalnom računaru programera.
• Prostor je izolovan u smislu da ne utiče na ostale učesnike na projektu.
• Programer može preuzeti nove promene sa linije koju razivija na kontrolisan način.
• Često programeri imaju više radnih kopija na svom računaru (različiti projekti na kojima rade).

2.6. Trajna zabeleška (commit operacija)

Programer može izmene iz lokalnog radnog prostora trajno zabeležiti u VCS repozitorijumu i omogućiti ostalim učesnicima uvid u izmene putem commit operacije.

2.7. Alternativni tokovi razvoja

• Projekat u svakom trenutku može imati više aktivnih linija razvoja.
• Razvijamo verziju 2.0 našeg proizvoda li još uvek održavamo verziju 1.x.
• Naš proizvod radi na više operativnih sistema (Linux, Windows, Mac).
• Alternativni tokovi razvoja se u VCS sistemima realizuju upotrebom grana.

3. Arhitekture i modeli

3.1. Arhitekture sistema za kontrolu verzija

4. Modeli repozitorijuma

4.1. Modeli VCS repozitorijuma

Najčešće korišćeni modeli VCS repozitorijuma su sledeći:

• Skup fajlova sa promenama.
• Virtuelni fajl sistem sa verzijama.
• Usmereni aciklični graf skupova promena.

4.2. Skup fajlova sa promenama

• Korišćen u starijim sistemima za kontrolu verzija (SCCS, RCS, CVS).
• Svaki fajl je praćen nezavisno tako što se čuvala bazna verzija i promene koje su sledile.
• Verzija svakog fajla se nezavisno uvećavala i kreiranje verzije celog projekta se obavljalo označavanjem (tagging) ili se, kao odrednica za identifikaciju verzije, koristio datum i vreme.
• Podrška za transakcije i obezbeđivanje konzistencije repozitorijuma najčešće nije postojala ili je bila na niskom nivou.
• Ovakav model je dugo godina bio u upotrebi zbog svoje jednostavnosti.

4.3. Virtuelni fajl sistem sa verzijama

• Model korišćen kod subversion (SVN) VCS-a.
• Koristi koncepte klasičnih fajl sistema - fajlove i foldere.
• Svaka promena nad SVN fajl sistemom rezultuje novom verzijom celokupnog fajl sistema tj. rezultuje novim snapshot-om.
• Ako posmatramo fajl sistem kao dvodimenzionalnu strukturu onda se fajl sistem sa verzijama može posmatrati trodimenzionalno pri čemu je treća dimenzija vreme (odnosno verzije).

Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato: Version Control with Subversion

4.4. Virtuelni fajl sistem sa verzijama

• Operacije izmene su transakcione prirode sa ACID semantikom.
• Upotrebom klijentskog alata moguće je vratiti se na bilo koju verziju repozitorijuma u prošlosti.
• SVN koristi referenciranje delova stabla u određenim verzijama i čuvanje samo razlika koje su nastale u svakoj verziji.
• Kompleksnost operacije kopiranja i premeštanja fajlova i čitavih podstabala je O(1) i obavljaju se gotovo trenutno uz minimalan utrošak prostora (prostor potreban da se zabeleže reference na kopirani sadržaj).
• Operacije grananja (eng. branching) i označavanja (eng. tagging) se obavljaju operacijom kopiranja.
• Kopija podstabla će imati zajedničku istoriju sa originalom do trenutka kopiranja.
• Od trenutka kopiranja svaka kopija je nezavisna.
• Kopija podstabla predstavlja alternativni tok razvoja pa se može koristiti (i koristi se) kao grana razvoja.

4.5. Usmereni aciklični graf skupova promena

• Usmereni aciklični graf (Directed Acyclic Graph - DAG) skupova promena.
• Najčešće se koristi kod distribuiranih sistema za kontrolu verzija.
• Može se opisati kao graf čije su veze usmerene i kod koga ne postoje zatvorene jednosmerne putanje (acikličan je).

4.6. Usmereni aciklični graf skupova promena

• U odnosu na opšti DAG korišćena struktura ima ograničenja u pogledu broja mogućih ulaznih veza u svaki čvor.
• Ograničenja su sledeća:
  • Postoji tačno jedan čvor koji nema ulaznih veza. Ovaj čvor predstavlja početnu verziju repozitorijuma.
  • Svi ostali čvorovi imaju 1 ulaznu vezu ukoliko predstavljaju obične verzije ili 2 ulazne veze ukoliko predstavljaju spoj (merge) dve prethodne verzije (čvorovi V5 i V7 na slici).

4.7. Modeli upravljanja konkurentnim promenama

• Pesimistički (Lock-Modify-Unlock)
  • Konkurentne izmene se izbegavaju zaključavanjem
  • Primena moguća samo kod centralizovanih sistema
  • Mane:
    • Smanjena propusnost sistema - posebno izraženo kod projekata sa većim brojem učesnika,
    • Sindrom “otišao na ručak”.
• Optimistički (Copy-Modify-Merge)
  • Konkurentne promene se udružuju naknadno (operacija Merge).
  • Visoka propusnost - svaki učesnik može da ažurira proizvoljan artifakt
  • Mane:
    • Konkurentne promene mogu biti u konfliktu što se razrešava prilikom operacije spajanja.
    • Kod proizvoljnih binarnih fajlova gde semantika sadržaja nije poznata alatu ovaj pristup ne može da se koristi.

4.8. Modelovanje istorije

• Bazirano na zatečenom stanju - eng. Snapshot ili State-Based Versioning.
• Bazirano na promenama - eng. Changeset ili Change-Based Versioning.
• Većina današnjih sistema za kontrolu verzija koriste SS model u komunikaciji sa korisnikom. Korisniku je repozitorijum predstavljen kao niz stanja projekta u određenim trenucima vremena.
• Zbog ušteda u prostoru, interno se koriste CS mehanizmi tj. čuvaju se samo razlike u odnosu na prethodna stanja.

5. Merge, diff i patch

5.1. Spajanje konkurentnih promena - Merge

• Konkurentno razvijene promene pri korišćenju optimističkog pristupa moraju u nekom trenutku biti spojene.
• Podrazumeva kreiranje integralne verzije stavke konfiguracije od više nezavisnih verzija.
• Spajanje se sastoji od operacija poređenja, detekcije konflikata, razrešenja konflikata i spoja.
• Operacija razrešenja konflikata zahteva intervenciju korisnika.

5.2. Operacija poređenja

• Određuje razlike između dva CI.
• Za različite vrste CI koriste se različiti algoritmi.
• Na primer, različiti algoritmi se koriste u zavisnosti od toga da li je CI tekstulane ili binarne prirode.
• Većina VCS-ova tretira binarne fajlove kao sadržaj bez semantike. Određeni komercijalni VCS-ovi pružaju podršku za neke popularne binarne fajl formate.

5.3. Jedinica poređenja (Unit of Comparison - UC)

• Esencijalne operacije kontrole verzija su izračunavanje razlike dva CI-a, njihova reprezentacija i vizualizacija na ljudski čitljiv način u cilju analize promena i razrešavanja eventualnih konflikata.
• Da bi analizirali algoritme za poređenje stavki konfiguracije potrebno je uvesti pojam jedinice poređenja (Unit of Comparison - UC).
• Jedinica poređenja definiše granulaciju poređenja.
• Prilikom poređenja, ukoliko ustanovimo da su dve jedinice poređenja različite na bilo kom delu, smatramo da su u celosti različite.
• Kod većine sistem za kontrolu verzija jedinica poređenja je linija teksta za tekstualne artifakte i ceo fajl za binarne.

5.4. Određivanje, reprezentacija i čuvanje promene

• Naivan pristup - čuvanje svake verzije u celosti.
• Veliki gubitci prostora s obzirom da se dve sukcesivne verzije fajla u proseku razlikuju u svega 2%.
• Delta kodiranje (Delta encoding) - reprezentacija samo razlika između dve sukcesivne verzije.
• Propratni efekat je poboljšanje performansi jer je delta često dosta manja od originalne verzije a brzine procesora su za više redova veličina veće od brzina jedinica spoljne memorije.
• Razmena verzija između repozitorijuma - slanje delti.

5.5. Algoritmi za određivanje promena u tekstualnim CI

Izračunavanje delti obavlja se algoritmima koji se mogu podeliti u dve klase:

• copy/insert delta algoritmi:
  • Dobijanje odredišnog fajla od polaznog kreiranjem komandi kopiranja (copy) za delove koji su nepromenjeni i komandi dodavanja (insert) za delove koji su različiti.
  • Daje bolje performanse.
• insert/delete delta algoritmi:
  • Transformacija polaznog fajla u odredišni dodavanjem sadržaja koji postoji samo u odredišnom a ne i u polaznom (insert) i brisanjem sadržaja koji postoji samo u polaznom a ne i u odredišnom (delete).
  • Ova klasa algoritama je bazirana na algoritmima za određivanje najduže zajedničke podsekvence (Longest Common Subsequence - LCS – npr. Majersov algoritam). Ovaj algoritam se koristi u unix diff alatu.
  • Daje intuitivnije rezultate.

5.6. diff

• diff je unix komanda koja će za dva ulazna tekstualne fajla odrediti razliku i enkodovati je upotrebom jednostavnog delta kodovanja prikazanog na slici.
• Delta predstavlja skup komandi za dodavanje i brisanje linija.

5.7. patch

• Upotrebom ovako kodovane razlike, patch komandom možemo dobiti odredišni fajl od polaznog.
• Ova tehnika je osnova za izgradnju složenih VCS sistema.

5.8. Dvostrano spajanje

5.9. Trostrano spajanje

5.10. Trostrano poređenje - primer

5.11. Konflikti

• Javljaju se ukoliko je došlo do konkurentnih promena nad istim jedinicama poređenja.
• Neko mora da odluči koja izmenu treba zadržati a koju odbaciti.
• Ova operacija, koja zahteva manuelnu intervenciju, naziva se razrešavanje konflikata.

5.12. Spajanje konkurentnih promena nad tekstualnim CI

• Kod tekstualnih CI, kod kojih je jedinica poređenja linija teksta, najčešće se spoj obavi automatski bez pojave konflikata.
• Konflikt se javlja ukoliko je došlo do paralelnih izmena istih linija teksta od strane više programera.
• Najčešće onaj koji poslednji pokušava da zabeleži svoju promenu u repozitorijumu treba da razreši konflikt.

5.13. Spajanje konkurentnih promena nad binarnim CI

• Kod binarnih CI, jedinica poređenja je najčešće ceo CI tako da nije moguće automatizovati spajanje već se razrešenje konflikta vrši izborom jednog od konkurentno razvijenih verzija.
• Zbog toga se, kod binarnih fajlova, ažuriranje ne radi konkurentno.
• Jedan od mehanizama da se to obezbedi je korišćenje pesimističkog pristupa za binarne fajlove.

6. Modeli alternativnih tokova

6.1. Modeli alternativnih tokova ili grananja

• Odnosi se na organizaciju i upravljanje procesom kreiranja grana, trajnih zabeleški (commit) i operacije spoja (merge).
• Proces kreiranja grana podrazumeva imenovanje grana na određeni način i definisanje načina na koji se grane koriste.
• Često korišćeni termini su razvojne grane (development branches), grane za izdanja (release branches), grane za ispravke grešaka (bugfix branches) i sl.

6.2. Primer modela grananja - GitFlow