agosto 2013 Blog Posts

Microsoft ha schedulato una iniziativa molto interessante per il weekend del 13-15 Settembre: il Team Foundation Server 2013 Upgrade Weekend.

Cos’e’? E’ un weekend dove si puo’ aggiornare I loro TFS alla versione 2013 attualmente in preview con go-live, ma soprattutto ottenere supporto tecnico gratuito dal Microsoft CSS in caso di problemi!

Consiglio caldamente di unirvi a questa iniziativa molto utile: ci si può registrare qui in modo da far predisporre un numero sufficiente di persone al supporto.

Nonostante sia strettamente integrato con Team Foundation Server, InRealease – ad oggi – è un prodotto stand-alone.

È formato da tre componenti: un server, un client e da quanti deployer si vuole, installati sui server in cui si vuole fare il deploy dell’applicazione. Il tutto è così granulare che ricorda una matrioska.

Si crea quindi una Release. La Release è basata su un template che definisce le fasi e le azioni del deployment.

clip_image002

Si basa su Windows Workflow Foundation, ed è molto intuitivo. Sono presenti molte activity out-of-the-box e gli InRelease Components, che analizzeremo in un post separato spiegando cosa sono e come modificarli.
Per poter effettuare il deploy, il Template deve avere almeno un Environment, ossia un contenitore per I server di destinazione che fanno girare il Deployer. Nel mio caso, ho creato due environment (Sviluppo e Produzione), ognuno contenente un server (dev.domain.tld e prod.domain.tld).

Come potete vedere nella foto, in questo caso la pipeline del deploy è estremamente facile: si crea una cartella nel server interessato e ci si copiano dei file.

A questo punto il più semplice processo di release è basato sull’approvazione: si deve approvare il deployment e il suo completamento. È possibile approvare o meno sia dalla console sia dalla web interface.

clip_image004

Questi sono i concetti base di cui potreste avere bisogno per utilizzare InRelease :)

Dovrebbe essere noto a tutti che la best practice dice “Un workspace per Team Project”. Sfortunatamente non è sempre possibile renderla la soluzione di default, per varie ragioni (utenza tipica, etc.)

In Visual Studio 2013 la best practice è dentro il prodotto: il Workspace Mapping di default è esattamente one-per-project! Se provi a configurare un Workspace per un nuovo Team Project, ti verrà chiesto di farlo:

bp1

Dopo aver cliccato Configure, si andrà a mappare la root del Team Project in una specifica cartella utente:

bp2

bp3

E’ decisamente un bel passo avanti, visto che previene la creazione di un unico grande e monolitico workspace che poi presenterà tutti i classici problemi associati (performance in testa).

Nonostante TFS 2013 sia ancora una Preview, è totalmente compatibile con gli altri prodotti Microsoft.

Per attivare la sincronizzazione dei Work Item bisogna seguire la procedura TechNet standard, ma c’è bisogno di:

- Installare l’Object Model di TFS 2012

- Riavviare lo SCOM HealthService via PowerShell (restart-service HealthService)

- Una volta che ci si è connessi al server con il wizard, dovrebbe apparire un errore TF223006 che riguarda i tool a riga di comando. Non preoccupatevi! Salvate la configurazione e aggiungete manualmente il  Work Item Type OperationalIssue_11 dalla ISO o dal supporto di installazione di Operations Manager.

clip_image002

image

E funziona!

Non è qualcosa che ti fa gridare al miracolo, ma secondo me ha la sua dignità e otterrà ancora più importanza nelle prossime versioni.

Sto parlando del Visual Studio Notifications Center. È qualcosa che si basa sul Connected IDE, di cui probabilmente è il primo esempio dell’integrazione con Visual Studio, insieme ai Roaming Settings.

È una piccola icona in alto nell’IDE…

image

…che apre una finestra con le notifiche.

image

Secondo me è importante perché potrebbe essere l’hub per i contenuti informativi (supporto nell’installazione, scadenza della licenza) ma anche per gli aggiornamenti.