giovedì 4 giugno 2009
#
Ciao, eccomi dopo parecchio tempo a dare risposta ad un problema che mi ha creato qualche grattacapo negli ultimi giorni.
Il malvivente è Project Server 2007 e nello specifico il servizio che gestisce le code.
Mi è capitato di realizzare, su due macchine virtuali, un ambiente così configurato:
Macchina 1 (domain controller):
Windows Server 2003
Application Tier WSS 3.0
Application Tier Project Server 2007
Macchina 2:
Sql Server 2005
Il problema che si presentava era il seguente: ogni operazione che doveva essere gestita dalle code non veniva eseguita. Tutti i tasks erano in stato “Waiting to process” e da quello non si scostavano.
Al riavvio del Servizio, tuttavia, la situazione tornava a funzionare.
Dopo diversi tentativi ho notato che il malfunzionamento si presentava al riavvio delle macchine (ovviamente prima doveva essere avviata la Macchina 1, in quanto domain controller, successivamente la seconda).
Dopo un po’ di ricerche ed analisi ho svelato l’arcano.
Il servizio delle code viene, ovviamente, inizializzato all’avvio. Tuttavia alcune delle informazioni di inizializzazione vengono prelevate dal database (o meglio, da wss che si appoggia sul database).
L’ordine di avvio delle macchine (che purtroppo nel mio caso è obbligatorio) rendeva il servizio dedicato alla gestione delle code inconcludente.
Il servizio che gestisce le code di Project è soggetto ad un velo di instabilità (che il Service Pack 2 risolve in parte), se tuttavia dovesse capitarvi un problema analogo, controllate che non possa essere questo il motivo. Potrebbe risolvere qualche giorno di troubleshooting.
Ciao!
lunedì 30 marzo 2009
#
Eccomi qui, finalmente, a scrivere il mio primo vero post.
Tra le funzionalità di Team Foundation Server e l'altra, io trovo molto utile la possibilità di impostare le policies di checkin, ovvero la possibilità di dare delle guide che devono essere rispettate in fase di salvataggio nel repository.
Chi gestisce un progetto fa affidamento su queste policy per diversi motivi. Vuoi per valutare lo stato di avanzamento, vuoi per studiare la qualità, vuoi per mille altri motivi, ma se queste policies non vengono seguite, può essere assai difficile tenere sotto controllo lo sviluppo. Purtroppo (o per fortuna, dipendentemente dalle situazioni) non c'è modo per impore queste regole. E' possibile, infatti, bypassare una policy, previo inserimento di un commento. Le policies non sono binari che si è costretti a seguire, ma linee guida che possono solo dare una direzione.
E' impensabile andare a guardare tutti i changeset con relativi commenti. Inoltre potrebbe essere utile avere un report schedulato in modo tale da inviare una mail al PM con i dettagli tutti il lunedì mattina.
Perchè, allora, non crearsi un report ad hoc? Un report che mostri i changeset (Id, data, chi ha effettuato l'operazione, commento) e sul quale si possano poi apporre dei filtri?
L'unico "problema" nel realizzare un report di questo tipo potrebbe essere quello di crearsi la query. Nulla davvero di più facile. I database sui quali si deve operare sono 2: TfsVersionControl e TfsWarehouse. Il primo utilizzato per prelevare le informazioni di check-in ed il secondo le informazioni sull'utente.
SELECT
p.ChangeSetId,
cs.CreationDate,
cs.Comment as CheckInComment,
p.Comment as OverrideComment,
pr.Person,
pr.Email
FROM
TfsVersionControl..tbl_PolicyOverride p
INNER JOIN
TfsVersionControl..tbl_ChangeSet cs ON p.ChangeSetId=cs.ChangeSetId
INNER JOIN
TfsVersionControl..tbl_Identity i ON cs.OwnerId=i.IdentityId
INNER JOIN
TfsWarehouse..Person pr ON i.DisplayName=(pr.Domain+'\'+pr.Alias)
Data questa query, il report viene da sè. Si possono creare filtri sull'id, sulla data, sull'utente e ovviamente sul commento di override, che interessa a noi.
Come primo intervento, non ho sicuramente fornito perle particolarmente preziose, tuttavia durante la valutazione di un progetto e il suo proseguimento, sapere quando e chi non ha rispettato le policy può essere molto utile.
Ciao a tutti
-Diego-
venerdì 27 marzo 2009
#
Oggi mi sono trovato ad affrontare un problema non indifferente.
Lo scenario che volevo produrre era la seguente (estratto dal contesto vero e proprio che ora non interessano particolarmente):
Ho due liste (source e dest) e due ruoli (writer e manager).
I writers devono popolare la prima lista. Al termine della compilazione, un workflow, deve copiarmi i dati in dest. Su questa lista i managers devono effettuare altre operazioni. Writer non deve avere alcun permesso alla lista dest. Manager, invece, non deve avere accesso nè in lettura nè in scrittura su source. La soluzione doveva richiedere poco tempo per essere implementata e, se possibile, doveva essere realizzata utilizzando Sharepoint Designer.
Il problema sorgeva dal fatto che il contesto del workflow è lo stesso dell’utente che l’ha scatenato. Questo significa che se writer non ha permessi sufficienti per scrivere su desc, nemmeno il workflow li avrà. Dopo un po’ di ricerca, su CodePlex, ho trovato una custom activity (a dire la verità è un pacchetto) che consente di scrivere su liste di qualunque sito, senza avere necessariamente permessi di scrittura. La realizzazione del Workflow, quindi, ha richiesto pochi minuti di tempo per essere portata a termine.
Oltre a questa activity sono presenti altri 4 o 5 tasks molto utili.
http://www.codeplex.com/SPDActivities
P.s.
Non mi sono soffermato sulla realizzazione specifica del workflow perchè non era scopo di questo post oltre al fatto che l’implementazione e le necessità erano molto più complesse. In caso venga richiesto, eventualmente, farò un altro intervento dove elencherò gli steps completi.
Buon weekend a tutti!
lunedì 23 marzo 2009
#
Immaginate una situazione di questo tipo:
Il cliente gestisce il versioning dei propri sorgenti utilizzando SubVersion. Internamente sfruttate Team Foundation Server 2008. Se si copiasse sotto SV i progetti così come sono, all’apertura degli stessi, il cliente, si troverebbe ad avere finestre di dialogo che avvisano dell’impossibilità di connettersi al source control del TFS.
Una situazione simile si può verificare anche più frequentemente, dovendo passare i progetti a collaboratori esterni.
Come si risolve questa situazione?
Banalmente facendo l’unbind dei progetti:
File –> Source Control –> Change Source Control
Dalla finestra di dialogo che viene aperta, effettuare l’unbind dei progetti da copiare.
Non ho certo spiegato qualcosa trascendentale, per molti sarà sicuramente acqua calda, tuttavia, per esperienza, assicuro che molti si saranno chiesti come passare ad altre persone dei progetti che avete sotto Source Control
Ciao!
sabato 21 marzo 2009
#
Eccomi!
Finalmente sono presente anche io con il mio blog.
Da qui in avanti spero di riuscire ad offrire il mio contributo diffondendo quello che la mia esperienza mi porterà a conoscere ed apprendere.
Non ho la presunzione di insegnare nulla a nessuno, la mia intenzione è la semplice condivisione. Su queste basi chiedo a chiunque di commentare quanto da me scritto, di sottolineare i miei errori e di aiutarmi ad accrescere la mia esperienza e nello stesso tempo spero di riuscire alleggerire i grattacapi di chi non ha ancora vissuto le mie stesse esperienze.
Buon weekend a tutti.
Ci leggeremo presto.
-Diego-