ASWI - Pokročilé softwarové inženýrství » ASWI 2021 » Rozšíření Genealogy pluginu (CATVUSA) - iOI

h1. Konvence

Zde jsou popsána pravidla pro vývoj produktu.

h2. Verzování

Verzování produktu je těsně spjato s vývojovými iteracemi. Na konci každé iterace musí vzniknout jedna production-ready verze produktu.

Název verzí produktu se skládá z prefixu *@ioi-@*, který následují čísla major a minor verze oddělené tečkou.

Major verze je číslo iterace, ke které se verze vztahuje.

Minor verze se začíná s každou iterací číslovat od 0 a při každém commitu související s toutéž iterací se číslo inkrementuje o 1.

Příklad první verze produktu z 3. iterace: *@ioi-3.0@*

Příklad verze produktu z 4. iterace po dvou mergnutých hotfixech: *@ioi-4.2@*

h2. Git

Pravidla pro tvoření větví ve VCS git.

Následující pravidla jsou převzata a mírně upravena z článku:

https://nvie.com/posts/a-successful-git-branching-model/

h3. main

* hlavní release větev

* pojmenována jako *@main@*

* HEAD obsahuje vždy nejnovější production-ready verzi produktu

* do této větve se merguje z release a hotfixes větví

* každý commit musí být jednoznačně identifikovaný názvem verze produktu

h3. develop

* hlavní vývojová větev

* pojmenována jako *@develop@*

* HEAD obsahuje vždy nejnovější dodané vývojové změny

* mohou zde probíhat menší bugfixy

* do této větve se merguje z vývojových větví a slouží jako zdroj pro větvění pro release větve

h3. vývojové větve

* každá feature, bugfix nebo enhancement musí mít vlastní větev

* na těchto větvích probíhá samotný vývoj

* pojmenování libovolné, pokud nekoliduje s názvy *@main@*, *@develop@* a *@release-*@*, musí však reflektovat podstatu feature

* větvit by se měli z větve *@develop@*

* mergovat zpět se musí pouze do větve *@develop@*

* merge commit by měl být pro identifikaci jednoznačně spárován s příslušným issue (v commit message)

h3. release větve

* přípravné větve pro budoucí release, tzn. production-ready verzi produktu

* každá release má svou vlastní větev

* pojmenování s prefixem *@release-@*, po kterém následuje název verze produktu

* na těchto větvích nesmí probíhat žádné přidávání funkcionality nebo jiné změny, než opravy bugů či změny související s procesem release (číslování verzí atp.)

* větvit se musí z větve *@develop@*

* všechny změny se nakonec zmergují do větve *@main@* a také zpět do větve *@develop@*

* merge commit do *@main@* větve musí být pro identifikaci verze jednoznačně identifikován tagem

h3. hotfixes větvě

* větve pro kritické opravy kódu v *@main@* větvi

* větvit se musí z *@main@* větve

* mergovat se musí zpět do *@main@* větvě a současně i do větve *@develop@*

* merge commit do *@main@* větve musí být pro identifikaci verze jednoznačně identifikován tagem

ukázkové schéma správného větvění při vývoji:

!{width:30%}git_branching.png!

zdroj: https://nvie.com/posts/a-successful-git-branching-model/

h2. Komunikace

* *Zákazník:* Microsoft Teams - Chat

* *Mentor:* Microsoft Teams - Tým iOI - Genealogy (CATVUSA)

* *Tým:* Discord

h2. Projekt

* Vedoucí týmu založí hlavní úkol práce. Každý účastník projektu si vybere část práce za kterou bude zodpovědný a vytvoří si vlastní podúkoly daného zadání.

* Na začátku iterace se status *ACCEPTED* nastaví vždy na všechny úkoly. 

* Jakmile někdo z tymu si zvolí nějaký task, tak změní status úkolu na *ASSIGNED*. 

* Po dokončení úkolu se status nastaví na *RESOLVED*. 

* Vedoucí tymu na konci každé iteraci nastaví statusy z *RESOLVED* na *CLOSED*.