Spesso molti pensano che la siccome la Team Foundation Server Integration Platform e’ un progetto open-source non abbia supporto.
 
SBAGLIATO!

E’ l’unica soluzione di migrazione e sincronizzazione supportata da Microsoft. Ma solo se si scarica il package dalla Visual Studio Library, che e’ quello della versione stabile e supportata. Se avete un problema, potete chiamare il Customer Support Service e chiedere supporto.

Invece se si scarica il package da Codeplex (che contiene anche il codice sorgente) potreste avere delle beta, o delle version diverse da quelle supportate, che quindi non vengono coperte dal CSS.

Spero che questo chiarisca le cose su questo argomento molto importante

A volte capita che l’amministratore del TFS deve risolvere problemi causati da utenti inesperti (o che non hanno effettuato un training), e forse il problema piu’ comune e’ quello di effettuare l’undo di “check-out fantasma”.

Ecco la risposta: Attrice Corporation Team Foundation Sidekicks. Bello. Ma a volte non si possono utilizzare tool di terze parti, e quindi ci si deve accontentare di cio’ che Microsoft propone out-of-the-box nell’installazione di Team Foundation Server.

Ecco quindi la vera risposta, sin da Team Foundation Server 2005: aprire il Developer Command Prompt, e lanciare il commando tf undo con gli switch appropriati.

Qui trovate la relativa documentazione.

Abbiamo visto come ridurre il divario tra team di sviluppo e team di Operations in un modo rapido e veloce. C'è molto di più da fare, e tonnellate di strumenti che ci possono aiutare: il principale è, per eccellenza, IntelliTrace.

Quando creiamo un Operational Issue, un log di IntelliTrace è allegato automaticamente al Work Item:


ma è dotato solo di un sottoinsieme minimo di informazioni relative alla segnalazione, e probabilmente non contiene tutto il necessario.
Il primo modo sarebbe ottenere manualmente un file .iTrace con la nostra configurazione custom per raccogliere dati. Niente di così difficile, ma se il motto principale di DevOps è "automatizzare tutto", stiamo andando contro di esso.

O - meglio - posso chiedere ad Operations di registrare un log IntelliTrace dettagliato, naturalmente il tutto integrato con Team Foundation Server.

Si deve solo impostare il Work Item in "Awaiting evidence", con una nota di risoluzione dicendo di fornirme un file .iTrace.

Per raccogliere queste informazioni, basta far partire il Collector dalla console di SCOM ed eseguire l’applicazione incriminata. Facilissimo



Cosi si può raccogliere uno snapshot dello stato attuale del pool di applicazioni coinvolto, replicando / facendo replicare lo scenario dell'utente, e quindi il nuovo file IntelliTrace puo’ essere allegato al Work Item correlato

Tutti i file di IntelliTrace possono essere memorizzati in una share di rete, una cartella per ogni alert, quindi ricordatevi di tenere d'occhio la dimensione dei file salvati!

L’utente clicca sul tasto e…

KABOOM!

Il primo passo essenziale per un sistema di Developer Operation è intercettare gli errori in produzione e salvarli in dei Work Item per il team di Engineering. Come abbiamo visto nel post precedente, abbiamo a disposizione un nuovo, dedicato Work Item per questo: Operational Issue.
Una volta trovato un bug in produzione uno o più alert vengono scatenati per segnalare la cosa. L’alert può arrivare via email oltre che nella console di SCOM, per innescare un processo sia formale che informale nell’organizzazione.

E non si tratta di un semplice ‘avviso’: l’alert include tutte le informazioni che manderemo agli sviluppatori tramite l’Operational Issue.



Una volta modificato lo stato ad Assigned to Engineering, questo viene spedito. Sorvolando su tutte le tab (non sarebbe ‘per principianti’ altrimenti ) diamo un’occhiata al box Alert Description. Ci presenta un link ad un URL che usa porta 45451. Cos’è?!



E’ il risultato dell’acquisizione da parte di Microsoft di AVICode. Un sistema completo di application monitoring è stato integrato in SCOM, e tutte le informazioni che cattura [davvero molte] vengono renderizzate da questo servizio.

Un’ultima nota: un file IntelliTrace è aggiunto al Work Item, ma non è grande come un normale file .iTrace. Vedremo in un altro post perchè, e come integrare IntelliTrace nel nostro workflow di DevOps.

Nel prossimo post invece vedremo cosa accade dall’altro lato, ossia in Engineering quando qualcosa viene segnalato da Operation attraverso una Operational Issue.

Sicuramente DevOps è un argomento caldo adesso e lo sarà ancora di più nel prossimo futuro. Quindi con questo post comincia una piccola serie di articoli dedicati all’integrazione fra i due mondi.

I prerequisiti sono due: Team Foundation Server 2012 Update 1 o superiore e System Center Operations Manager 2012 SP1.

Prima di tutto si deve impostare il server e la Team Project Collection per l’applicazione da monitorare:

Dopodichè dobbiamo impostare i progetti per i quali il nuovo Work Item Type – Operational Issues – sarà salvato. Possiamo anche impostare l’Area Path appropriato.

Oltre alla connessione fra SCOM e TFS, un grosso aiuto per connettere Operation e Engineering ci è fornito dagli Alert. Qualunque sia lo stato di un cambiamento di un’Operational Issue, un alert viene fatto scattare per l’amministratore che si occupa delle Operation:

Infine abbiamo una dashboard che ricapitola le informazioni essenziali. Ho evidenziato la possibilità di importare le Operational Issue: è davvero importante quando dobbiamo consolidare, un tema spesso poco considerato ma essenziale.