[TFS]: Check-In policy skippate

UPDATE: dopo le segnalazioni di Lorenzo e Janky nei commenti, qui c’è spiegato come ottenere lo stesso risultato in modo corretto, usando l’object model di TFS

Come molti ormai sapranno, utilizzando TFS è possibile impostare una serie di check-in policy (approfondisco la cosa in un altro post). In breve, queste policy consentono di evitare il submit “selvaggio” di codice nel repository migliorandone, se vogliamo, la qualità.

Una delle chek-in policy che abilito immediatamente quando avvio un progetto è relativa ai Work Item. In sostanza, ogni check-in nel repository DEVE essere associato ad un Work Item. Questo permette in prima battuta di tenere traccia del lavoro svolto e di capire quali righe di codice sono state modificate per implementare una certa modifica o per correggere un bug. In situazioni più evolute, può permettere la promozione del codice negli step successivi del processo di sviluppo (sviluppo, testing, preproduzione, produzione).

C’è però una esigenza che mi si è posta oggi: durante la fase di chek-in, in presenza di una rule, viene data la possibilità allo sviluppatore di “saltarla”, a patto però che ne venga spiegato il motivo con un commento (obbligatorio). Quello che mi serviva, era un elenco dei chek-in fatti skippando le regole. Fortunatamente, alla base di TFS c’è Sql Server. Sono bastati quindi pochi minuti per capire dove reperire le informazioni e scrivere la seguente query:

   1: select [changeset].[changeset id]
   2:     , [changeset].changeset
   3:     , [Code Churn].Date
   4:     , [Person].Person
   5:     , [changeset].[Policy Override Comment]
   6: from [work item]
   7:     join [work item changeset] on [work item].__Id=[work item changeset].[work item]
   8:     right join [Changeset] on [work item changeset].Changeset=[Changeset].__Id
   9:     join [Code Churn] on [Changeset].__Id=[Code Churn].Changeset
  10:     join [Person] on [Code Churn].[Checked in By]=[Person].__Id
  11: where [changeset].[Policy Override Comment] is not null
  12: order by date desc

Il risultato della query è:

changeset id changeset Date Person Policy Override Comment
848 Changeset 848: Modific … 2008-08-26 Mighell Regola skippata
846 Changeset 846: Escluso … 2008-08-25 Mighell Regola skippata

(2 row(s) affected)

Ritengo questa sorta di report molto utile, specie nella fase iniziale di utilizzo dello strumento da parte di un team già avviato (e non abituato ad una sorta di formalizzazione dei processi di sviluppo). Nel mio caso specifico, cercherò di capire con lo sviluppatore in questione i motivi che lo hanno spinto a bypassare la regola. Potrebbe essere inesperienza o eccessiva granularità dei WorkItem.

IMHO, chiarire questi punti subito è importantissimo, specie se si vuole arrivare alla promozione automatica del codice nei diversi ambienti. Di fronte alla situazione evidenziata dalla query, si corre il rischio di non promuovere tutto il codice, con rischi facilmente immaginabili.

TFS non è assolutamente (solo)un repository di codice sorgente. E’ uno strumento che ti spinge ad usare una metodologia, ti spinge ad organizzare per bene il lavoro ed a farlo meglio.

Enjoy Smile

PS: non so se la query che ho scritto è ottimizzata o se c’è già qualcosa che mi tira fuori le informazioni in altri modi, quindi prendetela “as is”, e se avete qualche suggerimento, non esitate a contattarmi o a commentare questo post.

Technorati Tags: ,,