Iterace 3 zadavatel dotazy 2 » Historie » Revize 4
Revize 3 (Štěpán Faragula, 2025-04-01 09:54) → Revize 4/7 (Štěpán Faragula, 2025-04-01 09:55)
h1. 3. iterace - Schůzka se zadavatelem ohledně technických dotazů 2 ---- h3. Informace o schůzce * *Datum: 1.4.2025* * *Čas: 10:00* * *Forma: online přes Teams* h3. Účastníci: * Bc. Jakub Pavlíček, jpvlck@students.zcu.cz * Bc. Štěpán Faragula, farag844@students.zcu.cz h3. Poznámky ze schůzky Zeptali jsme se na dotazy: # Jak máme uložit data do tabulky <code>project</code>? Je <code>startDate</code> datum prvního commitu? ** Ano, <code>startDate</code> je datum prvního commitu. ** Ne každé ALM má svůj vlastní koncept pro startdate, máme vzít jakékoliv první datum čehokoliv (první commit / první změna v projektu čehokoliv) *** <code>startDate</code> máme uložit na konci dolování až po tom, co budeme znát všechny <code>work_item</code> a <code>configuration</code> *** Na konci vybereme položku s nejnižší hodnotou # V tabulce <code>work_unit</code> je atribut <code>progress</code> nastavený na NOT NULL, jakou hodnotu zde máme nastavit pro GitHub pumpu? ** Máme nastavit 0, tak jak děláme teď # Máme dodržovat strukturu dat v ukázkových datech? Např. že URL GitHub projektu končí koncovkou <code>.git</code> či název <code>project_instance</code> obsahuje i datum. ** Je to jedno, ale u Git pumpy to dává smysl, u GitHub pumpy to může být jinak *** Dříve bylo nutné zadat .git kvůli knihovně JGit, protože to procházelo Git pumpou, když se repository muselo stáhnout na lokál ** Datum u <code>project_instance</code> = datum těžení (nemusíme vyplňovat, sloužilo pro debug, můžeme ignorovat) # Můžeme v tabulce <code>project_instance</code> do atributu <code>description</code> dát text z About na GitHubu? Tento text je uložen v atributu <code>description</code> tabulky <code>project</code>, takže bychom ho ukládali i zde (tj. <code>project_instance.description</code> by byl stejný jako <code>project.description</code>). ** Může být v obojím ** Otázka, jestli dávat podle délky (nejdelší popis je správný), nebo appendovat -> víc detailnější *** Na <code>description</code> nebude žádná analýza viset, jde spíš o orientační záznam a lepší vědět co nejvíce informací (appendování) ** <code>project_instance</code> <code>project_instance<code> může mít každá jiný název, u těch se vezme nejdelší možné jméno (dobrá heuristika, fungovalo dříve) # V tabulce <code>role</code> jsou uloženy role (v případě GitHub repozitáře), které se nepoužívají, např. documenter, tester apod., máme je tedy také vždy vytvářet? Můžeme v GitHub pumpě mapovat roli <code>Contributor</code> na SPADe <code>Developer</code>? ** Ano, je to tam z důvodu, když se chtějí lidi po těžení přemapovat *** Člověk reálně ví, jaké role zastává a měli bysme umožnit přemapování dat, když už budou v databázi a budou se nad nimi dělat analýzy ** I u ostatních enumů bysme měli vytvářet všechny *** Dává smysl u stavů, resolutions *** Priority nejspíše ne ** Contributor a developer dává smysl # Máme počítat s tím, že Git pumpa se bude spouštět také na lokálním repozitáři, tj. bez zadaného URL? ** Není pro to rozumný usecase, i kdyby chtěl uživatel těžit na lokále, tak repozitář spíš zvěřejní online a vytěží *** Důvod: na lokále jsou necommitované změny a ty nás nezajímají # U Git pumpy, do jaké tabulky máme ukládat změny souborů (tj. smazán, přidán, upraven)? Co všechno by měla Git pumpa umět? Naše zatím umí dolovat: <code>Identity</code>, <code>Person</code>, <code>Commit</code>, <code>Tag</code>, <code>Branch</code>, <code>Project</code>, <code>ProjectInstance</code> a <code>ToolInstance</code>. ** work_item_change -> atribut name ** U čistě gitové pumpy není nic jiného co by se dalo těžit, takhle stačí ** Configuration person relation se dá najít přes parsování řádků na commit message *** Lze se spoléhat na formát, kde je na konci commitu je "Reviewed by: ...", můžeme splitnout dvojtečkou a vzít člověka # V GitHub pumpě, jak máme těžit tabulky <code>iteration</code>, <code>phase</code>, <code>milestone</code>? U <code>iteration</code> a <code>phase</code> jsou v ukázkových datech stejná data, proč? V <code>milestone</code> není nic, proč? Když GitHub milestone nemá žádný issues, máme milestone i tak těžit? ** Data u <code>phase</code> a <code>milestone</code> jsou stejné kvůli testům ** U těchto dvou položek je lepší je dávat do iterace, protože to více odpovídá skutečnému kontextu. *** Vše dáme do iterace, zbytečné dávat data do obou ** Milestones neřešíme vůbec *** Velmi zřídka se dá najít koncept v ALM který by jim odpovídal *** Spíše odpovídá popisu na Wiki a to je moc složitý koncept těžení *** Uživatel si dodefinuje sám ** Když github nemá issues, i tak to máme těžit, je to zajímavá informace # Když ukládáme časy do tabulek, máme vždy používat časová pásma těch akcí, nebo naše? Tj. <code>issue.createdAt() = "Mon Jun 01 19:10:43 CEST 2020"</code> -> <code>“2020-06-01T19:10:43Z"</code> s Timezone, nebo <code>"2020-06-01T17:10:43Z"</code> bez Timezone (tj. -2 hodiny). ** Bez timezone a vše máme převést na UTC ** Lidé mohou commitovat z různých timezone, takže je potřeba standarzidovat # Jaký význam má relace mezi <code>work_item</code> a <code>configuration</code>? ** id w_i = id configuration *** Relace 1:1 ** configuration je jeden z typů work itemu (speciální typ work_item) *** configuration je stejné rozšíření wor_itemu stejně jako je work_unit rozšíření work_itemu *** configuration obená = změna ticketů/artefaktů *** commited = worklog (kdy se vytvořil záznam, kdy se strávil ten čas, to může být i zpětně) ** v PDF je hierarchická struktura mezi configuration ---- Autor: Štěpán Faragula Datum: 1.4.2025 Stav: hotový