Akce
3. iterace - Schůzka se zadavatelem ohledně technických dotazů 2¶
Informace o schůzce¶
- Datum: 1.4.2025
- Čas: 10:00 - 11:00
- Forma: online přes Teams
Účastníci:¶
- Bc. Jakub Pavlíček, jpvlck@students.zcu.cz
- Bc. Štěpán Faragula, farag844@students.zcu.cz
Poznámky ze schůzky¶
Zeptali jsme se na dotazy:- Jak máme uložit data do tabulky
project
? JestartDate
datum prvního commitu?- Ano,
startDate
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)
startDate
máme uložit na konci dolování až po tom, co budeme znát všechnywork_item
aconfiguration
- Na konci vybereme položku s nejnižší hodnotou
- Ano,
- V tabulce
work_unit
je atributprogress
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
.git
či názevproject_instance
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
project_instance
= datum těžení (nemusíme vyplňovat, sloužilo pro debug, můžeme ignorovat)
- Je to jedno, ale u Git pumpy to dává smysl, u GitHub pumpy to může být jinak
- Můžeme v tabulce
project_instance
do atributudescription
dát text z About na GitHubu? Tento text je uložen v atributudescription
tabulkyproject
, takže bychom ho ukládali i zde (tj.project_instance.description
by byl stejný jakoproject.description
).- Může být v obojím
- Otázka, jestli dávat podle délky (nejdelší popis je správný), nebo přidávat k existujícím -> víc detailnější
- Na
description
nebude žádná analýza viset, jde spíš o orientační záznam a lepší vědět co nejvíce informací (appendování)
- Na
project_instance
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
role
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 roliContributor
na SPADeDeveloper
?- 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 bychom 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ů bychom měli vytvářet všechny
- Dává smysl u stavů, resolutions
- Priority nejspíše ne
- Contributor a developer dává smysl
- Ano, je to tam z důvodu, když se chtějí lidi po těžení přemapovat
- 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íš zveřejní online a vytěží
- Důvod: na lokále jsou necommitované změny a ty nás nezajímají
- Není pro to rozumný usecase, i kdyby chtěl uživatel těžit na lokále, tak repozitář spíš zveřejní online a vytěží
- 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:
Identity
,Person
,Commit
,Tag
,Branch
,Project
,ProjectInstance
aToolInstance
.- 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
iteration
,phase
,milestone
? Uiteration
aphase
jsou v ukázkových datech stejná data, proč? Vmilestone
není nic, proč? Když GitHub milestone nemá žádný issues, máme milestone i tak těžit?- Data u
phase
amilestone
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
- Data u
- Když ukládáme časy do tabulek, máme vždy používat časová pásma těch akcí, nebo naše? Tj.
issue.createdAt() = "Mon Jun 01 19:10:43 CEST 2020"
->“2020-06-01T19:10:43Z"
s Timezone, nebo"2020-06-01T17:10:43Z"
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
work_item
aconfiguration
?- id w_i = id configuration
- Relace 1:1
configuration
je jeden z typů work itemu (speciální typ work_item)configuration
je rozšířeníwork_item
, stejně jakowork_unit
je rozšířeníwork_item
configuration
= změna ticketů/artefaktůcommited_configuration
= worklog (nutné rozlišovat kdy se vytvořil záznam a kdy se strávil čas, může být i zpětně)- ve SPADe PDF je hierarchická struktura mezi jednotlivými typy
configuration
- id w_i = id configuration
- High-level má dobré schéma, dále to chce lépe popsat systém uvnitř Docker kontejneru (udělat nové, detailnější schéma)
- Bude tam popis naší abstraktní třídy na pumpy
- Popis jednotlivých tříd a rozhraní, pak jak jsou implementovány v jednotlivých pumpách
- DAO vrstva
- Můžeme tam zanést i věci co se budou dělat v TSP2
- Modul na pseudonimizaci, modul na čtení konfigurací a na těžení jednotlivých konceptů
- Bude tam popis naší abstraktní třídy na pumpy
- Se zadavatelem jsme se dohodli, že dosavadní architektura je pro tuto iteraci dostačující, detailnější pohled můžeme udělat v další iteraci
- Pumpy by měly umožňovat zakomponovat různé
project_instance
(Redmine, GitLab) do již vydolovaného projektu- Tím se rozšíří sada lidí a identit (buďto se identity přiřadí k již existujícím lidem z vydolovaného
project_instance
, nebo se vytvoří nové)- Pozor, lidé jsou připojeni k
project
a ne kproject_instance
- Pozor, lidé jsou připojeni k
- Dále nám to i umožní propojení mezi ticketama a commity
- Když dotahujeme další instanci tak musíme dohledávat propojující dotazy
- Nutné projet všechny commit messages již uložených instancí -> nutné udělat manuálně zpětně
- Kdybychom spojovali 4 ALM dohromady, u přidávání posledního projdeme commit messages všech 3 předchozích
- Odkazy na tickety se mohou vyskytovat např. u Redmine i v popisu a komentářích
- Zachyceno v tabulce
work_item
odkazem sama na sebe (odkaz ticket -> ticket) - Vše se propojí v tabulce
project
- Zachyceno v tabulce
- Tím se rozšíří sada lidí a identit (buďto se identity přiřadí k již existujícím lidem z vydolovaného
- GUI by mělo umožňovat
- Před těžením se zeptá, jestli bude těžit nový projekt nebo jestli bude přidávat do existujícího projektu
- Implementace přes CheckBox (chci/nechci přidávat do exitujícího) + SelectBox (když chci, do jakého konkrétně)
- Před těžením se zeptá, jestli bude těžit nový projekt nebo jestli bude přidávat do existujícího projektu
- Nové požadavky by bylo vhodné zprovoznit do konce TSP1 v základní verzi, funkcionalitu můžeme však přesunout do TSP2
- Důležité je zdokumentovat, co všechno jsme zprovoznili do konce TSP1
- Měla by být možnost připojení na vlastní reálnou databázi místo dockerizované
- Důvod: na tuto reálnou databázi se následně mohou napojit i jiné nástroje
- Tuto funkcionalitu máme naplánovat až na TSP2, zatím nedává smysl
Autor: Štěpán Faragula
Datum: 1.4.2025
Stav: hotový
Aktualizováno uživatelem Štěpán Faragula před 2 dny(ů) · 7 revizí