Qualche tempo fa Microsoft ha rilasciato (al termine dello sprint 34 ) un corposo upgrade a Team Foundation Service.

Questo oltre a introdurre svariate novità, espone per la prima volta un succosissimo servizio: la Continuous Deployment per progetti cloud.

Si tratta di una funzionalità che permette il deploy immediato e continuativo dopo la fase di build direttamente sui server di Azure, con un click e pochissima configurazione.

I prerequisiti necessari sono:

• Un Team Project all’interno di Team Foundation Service (ricordo che ora è in beta pubblica)
• Un sito su Windows Azure sul quale effettuare il deploy

Il Build Template è disponibile da subito, anche per Team Project creati prima dello sprint 34.

La configurazione necessaria su Windows Azure è minimale: basta creare un nuovo Cloud Service o Web Site…

…ed a seguire configurare l’integrazione con Team Foundation Server:

Ad oggi è necessario avere un account su Team Foundation Service, come detto, in quanto per questa funzionalità è stata implementata una infrastruttura OData attualmente non disponibile per la versione on-premise.

A seguire si deve selezionare il progetto desiderato:

Fine della configurazione!

Ora tutto quello che è necessario fare è creare una nuova Build Definition utilizzando il Template per Azure. Per avere uno scenario di Continuous Deployment è necessario impostarla in Continuous Integration, ovviamente. Manca solo un ultimo parametro da inserire…

…ossia il nome del Web Site creato prima

Come abbiamo visto in precedenza possiamo creare dei Deployment Package da utilizzare poi per effettuare la pubblicazione della Web Application sul server.

Ora vedremo come automatizzare il processo, sempre utilizzando la nostra fida Team Build.

Prima però abbiamo bisogno di un prerequisito: il Web Deployment Tool, scaricabile dal Web PI Installer, e l’unica configurazione da applicare è questa (sul server di destinazione).

Quindi, qual era il parametro da passare a MSBuild per creare il package? Era:

/p:DeployOnPublish=true

Ora abbiamo bisogno di qualche switch in piu:

/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=InProc /p:MSDeployServiceUrl=<server> /p:DeployIisAppPath="Default Web Site/<mypath>" /p:UserName=<domain>\user /p:Password=<password>

Crea un pacchetto che viene spedito al server con il WDT in esecuzione, ed automaticamente esegue lo script di installazione.

Cosa serve per effettuare un XCopy Deployment con Team Build?

Semplicemente il solito switch DeployOnBuild da passare come MSBuild Argument, e qualcosa in piu…

/p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempRootDir=\\<server>\folder

Una funzionalità molto poco conosciuta della Team Build è la possibilità di creare dei Deployment Package per la distribuzione degli applicativi da parte del server stesso.

E’ un procedimento estremamente semplice, basta creare una nuova Build Definition:

Ed aggiungere lo switch /p:DeployOnBuild=true ai parametri di MSBuild.

In questo modo in fase di compilazione verrà creata una cartella <Progetto>_Package…

…al cui interno troviamo il package di distribuzione.

Per eseguirlo si può utilizzare lo script .deploy o…aspettare un prossimo post

Una delle funzionalità poco conosciute del Version Control System di Team Foundation Server è la Baseless Merge.

Si tratta di una merge fatta fra rami ‘paralleli’, ossia non direttamente branchati l’uno dall’altro (due rami di release ad esempio).

Tecnicamente l’operazione corretta per effettuare una cosa del genere sarebbe di effettuare Reverse Integration sulla branch padre, e dopodichè propagare il tutto verso l’altra branch. Ma a volte è necessario non farlo e quindi passare per una Baseless Merge..

Questa è un’operazione che porta con se alcuni rischi: I Ranger sconsigliano questa operazione a meno che non sia evitabile, visto che le cancellazioni non sono replicate, e soprattutto non esiste alcuna forma di aiuto per i conflitti, che quindi vanno risolti manualmente.

Fino alla versione 2010, la Baseless Merge era presente ma non integrata in Visual Studio: per eseguirla, era necessario utilizzare tf.exe con gli switch appositi (tf merge /baseless …).

Con Visual Studio 2012 la Baseless Merge è stata integrata all’interno dell’IDE.

Se in questo scenario volessi effettuare una merge fra Feature1 e Feature 2…

…potrei farlo in modo molto semplice. Basta richiamare il Wizard di Merging…

…che mi avvisa esplicitamente che sto per eseguire una Baseless Merge.

Proprio in virtù del fatto che è una operazione rischiosa, può essere eseguita solo dal Wizard di Merging (o sempre da tf.exe) ma non dallo Hierarchy Viewer.