Projekt

Obecné

Profil

Akce
Historie

Wiki » Průběh 3 iterace »

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:

Poznámky ze schůzky

Zeptali jsme se na dotazy:
  1. Jak máme uložit data do tabulky project? Je startDate 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šechny work_item a configuration
      • Na konci vybereme položku s nejnižší hodnotou
  2. V tabulce work_unit je atribut progress nastavený na NOT NULL, jakou hodnotu zde máme nastavit pro GitHub pumpu?
    • Máme nastavit 0, tak jak děláme teď
  3. Máme dodržovat strukturu dat v ukázkových datech? Např. že URL GitHub projektu končí koncovkou .git či název project_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)
  4. Můžeme v tabulce project_instance do atributu description dát text z About na GitHubu? Tento text je uložen v atributu description tabulky project, takže bychom ho ukládali i zde (tj. project_instance.description by byl stejný jako project.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í)
    • 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)
  5. 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 roli Contributor na SPADe Developer?
    • 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
  6. 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í
  7. 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 a ToolInstance.
    • 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
  8. V GitHub pumpě, jak máme těžit tabulky iteration, phase, milestone? U iteration a phase jsou v ukázkových datech stejná data, proč? V milestone není nic, proč? Když GitHub milestone nemá žádný issues, máme milestone i tak těžit?
    • Data u phase a milestone 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
  9. 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 standardizovat
  10. Jaký význam má relace mezi work_item a configuration?
    • 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ě jako work_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
Dále jsme se bavili o schématu architektury systému
  • 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 pseudonymizaci, modul na čtení konfigurací a na těžení jednotlivých konceptů
  • 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
Poté nám přidal zadavatel nový požadavek týkající se způsobu pumpování a také GUI
  • 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 k project_instance
    • 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
  • 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ě)
  • 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
Nakonec ještě přibyl požadavek na CICD
  • 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 asi 18 hodin(y) · 9 revizí