Fivetran mantiene un dbt package per GitHub che trasforma i dati del proprio connettore in modelli pronti per l’analisi su issue, pull request e metriche di ciclo. Il post originale è del maggio 2020, ma il problema che il package affronta è rimasto identico: misurare il proprio processo di sviluppo senza costruirsi l’intera catena di join da zero.
Il problema sta nell’API
Come spiega Fivetran, l’API di GitHub separa le informazioni di contesto su issue e pull request — assignee, cronologia — in endpoint diversi. È una scelta comoda quando devi fare richieste mirate su un’informazione precisa, molto meno quando devi ricomporre tutto per l’analytics. Il connettore nativo porta issue, pull request e i relativi dati contestuali in un formato predefinito, documentato nello schema GitHub di Fivetran, e il package ci costruisce sopra il layer di modeling.
Cosa produce
Gli output principali dichiarati sono tre:
github_issues: un record per issue, arricchito con assignee, milestone e confronti temporali.github_pull requests: un record per pull request, con repository, reviewer e le durate tra richiesta di review, merge e review stessa.github metrics: metriche su pull request e issue create e chiuse per periodo — giorno, settimana, mese o trimestre.
Il package dipende dal dbt source package per GitHub, che viene scaricato automaticamente insieme al package principale e si occupa della pulizia leggera dei dati, della definizione di tabelle e colonne e dei test sulla sorgente. Nel mezzo ci sono modelli intermedi che costruiscono gli output finali.
Le domande a cui risponde
Fivetran indica alcune domande operative che i modelli permettono di affrontare: se il rapporto tra issue e assignee sia sproporzionato; quale sia la soglia temporale oltre la quale una pull request tende a cadere nel dimenticatoio; il tracking del completamento delle pull request per settimana, mese e trimestre; il tempo medio trascorso in ciascuno stadio di una pull request, utile per stimare quando una issue verrà chiusa.
Il suggerimento più sensato riguarda la combinazione delle sorgenti: usare GitHub come sorgente standalone oppure incrociarlo con software di project tracking come Jira o Asana, per leggere il processo di delivery completo e non soltanto la parte che vive nel repository.
Una cautela che il post non fa ma vale la pena aggiungere: il tempo di review e il time-to-merge sono metriche facili da raccogliere e altrettanto facili da usare male. Funzionano come diagnostica di processo — dove si accumulano le code, quali repository hanno bottleneck di review — non come misura di produttività individuale.
In sintesi
- Il dbt package di Fivetran per GitHub produce modelli su issue, pull request e metriche aggregate per giorno, settimana, mese e trimestre.
- Dipende dal source package per GitHub, che gestisce pulizia, definizione delle tabelle e test sulla sorgente.
- Il valore aumenta combinando i dati GitHub con quelli di Jira o Asana; le metriche di ciclo vanno lette come diagnostica di processo.
Fonte: Introducing the Fivetran dbt package for GitHub — https://www.fivetran.com/blog/fivetran-dbt-github
Hai qualcosa da aggiungere? Unisciti alla discussione.