Konvence¶

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

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

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/

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

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

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)

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

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:

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

Komunikace¶

• Zákazník: Microsoft Teams - Chat
• Mentor: Microsoft Teams - Tým iOI - Genealogy (CATVUSA)
• Tým: Discord

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.