Grazie a Team Foundation Build è possibile adottare pratiche di integrazione continua nel proprio progetto. In questa presentazione viene introdotta la struttura di tfs build assieme alle tecniche base per effettuare una customizzazione della build.
3. Essere agili in un mondo in rapido cambiamento Cicli di produzione agili richiedono procedure agili L’agilità richiede visibilità totale sul progetto Deve essere possibile verificare in ogni momento lo “stato di salute” del progetto
4. Monitoraggio costante del progetto Per approcciare con successo cicli di vita agili, è necessario avere visibilità massima sul progetto La situazione peggiore è quella in cui la visibilità è praticamente nulla Con visibilità ridotta, il pm può solamente effettuare ping sugli sviluppatori No Maybe Is the project finished? ONE WEEK LATER The customersaidit miss feature ABC Toomanytests are failing Westill miss the setup, oneday more Just one week more
5. Il concetto di “integrazione” Uno dei problemi maggiori di “visibilità” è il classico IntegrationHell Questo problema avviene quando le varie parti del sistema sono messe insieme per formare il prodotto finale
6. Il concetto di “integrazione” Solo sistemi con un design perfetto in un mondo perfetto non soffrono di problemi di integrazione Nei team standard, è molto difficile raggiungere un integrazione perfetta tra le parti al primo colpo
7. Il concetto di “integrazione” La soluzione più semplice al problema è integrare il più spesso possibile Questo approccio garantisce una maggiore visibilità, ed evita di posticipare i problemi che si possono incontrare durante l’integrazione
8. La vita realedi un progetto Molto spessoglisviluppatoriassumono come “statodi salute” del progettociòcheaccadenelloro pc Questomododipensare è riassuntodallafrase “It works on my machine” Solitamentequindimoltiaspettivengonodimenticati o sottovalutati Installer Deploy in produzione Configurazionedei server Security (sviluppatorichelavorano come admin)
9. Esempiotipico Setup diapplicazioni windows Creareil setup di un progetto è solitamente (purtroppo) l’ultimaoperazionechevienefatta, spessodifretta Si credeerroneamentecheesista un magico tool che con due click faccia un setup perfetto In applicazioni non banaliquesto non è vero Creare e manutenere fin dall’inizioil setup di un progettopermettediaffrontaresubitoiproblemi
10. Come integrare Integrare subito il progetto, ovvero rendere il progetto fruibile al cliente fin dalla prima feature implementata I problemi vengono affrontati poco a poco, il progetto è quasi sempre in uno stato “rilasciabile”
11. Macchine di Integrazione o Build Il maggiornumerodioperazionidiintegrazionedeveessereautomatizzatatramite script Questi script verrannoeseguitiautomaticamentedamacchinedi Build TFS supportanativamentequestoconcettotramitei “build agent” e Tfs build BuildAgent TFS BuildAgent
21. Crearepiù script differenti Si possonocrearepiù script differenti, ogniunodeiqualideputato ad operazionidifferenti Situazionetipica Compilaretuttiiprogetti ad ogni check-in Eseguirei test ad ogni check-in ma non piùspessodiunavoltaogniora. Eseguireoperazioni molto pesanti o test dicaricounavolta al giorno (nightly build) Follow the ten minute rule
22. Tfs e frequenzadelle build TFS supportamoltiscenari Compilazione ad ognicheckin (continuous) Compilazione a certiintervalli(Es. nightly build) Compilazionemanuale Compilare ad ogni check-in, ma non piùspessodi un datointervallo Build Check-In Check-In Check-In Build Check-In TFS Check-In
23. Punti di estensione Come estenderetfs build per soddisfareesigenzespecifiche
24. Come estendere tfsbuild TFS 2008 supportal’esensionetramiteMsBuild Si possonoeseguireoperazioni custom scrivendodei Custom Task dimsbuild La conoscenzadiMsBuild è comunqueimportante, perchè è possibileusareipropri Custom Task anche in TFS 2010 MsBuildvienecomunqueusato per la fasedicompilazione e puòessereusato per customizzare la compilazionedeiprogetti(csproj, vbproj, etc)
25. Come estendere TFS 2010 build Use a MSBuild Activity to call MSBuild wrapper around a MsBuild task
26. Come estendere TFS 2010 build Use a MSBuild Activity to call MSBuild wrapper around a MsBuild task
27. Come estendere TFS 2010 build Wrap MsBuild task in a custom Workflow Activity
28. Come estendere TFS 2010 build Wrap MsBuild task in a custom Workflow Activity
34. Perchè twitter Disponibilesumoltepiattaforme Disponibilesututti I browser come plugin Affidabile e facile dausare. Puòesseresottoscritto o menodallepersoneinteressate BuildAgent
35. Tweet from MsBuild Demo di tweet in una build con approccioMsBuildtask e Custom Action
36. Come inserireuna custom activity Nella Beta2 per inserireuna custom activity è necessarioadottareparticolariaccortezze Il workflow diprocessodeveessereaggiuntoedaperto in un progettodi visual studio Il progetto in cui siapreil workflow deve fare parte diunasoluzione dove è caricatoilprogettochecontiene la custom activity
37. Lab – Deploy di web application Deployare una web application aggiornando nel contempo il database e l’istanza di IIS nel server di test.
38. Ambiente Tfs Visual studio Database Server Web Server Tuttopuòcomunqueesseremessosu un unicamacchina
39. Fase 1 – ilprogetto Creareuna solution con due progetti Un database project con lo schema dinorthwind Un progetto web con unasemplicepaginachemostrai clienti Creare un modello entityframework Nella default.aspxinserire un entityDataSource Nella default.aspxinserire una gridview
40.
41. Fase 2 – Creare una build e configurare il deploy del database Creare una build per la soluzione Creare una copia del workflow in modo da poterlo customizzare Localizzare nel workflow il punto dove vengono terminati i test.
42. Fase 2 – creare la build e configurare il deploy del database Quando si crea la build, la drop share folder deve trovarsi nel test web server Il test web server può comunque essere per questo lab anche la macchina virtuale dove gira tfs e visual studio
43. Fase 3 inserire la condizione ed una sequenza Inserire una condizione (cerchiata di rosso nella schermata precedente) al cui interno inserire una sequence La condizione da inserire è BuildDetail.TestStatus <> BuildPhaseStatus.FailedAndAlsoBuildDetail.CompilationStatus <> BuildPhaseStatus.Failed Cambiare il nome della condizione in qualche cosa di più significativo, ad esempio “If can deploy database”
44. Fase 4 inserire le azioni Inserire tre azioni come in figura Una convertWorkspaceItem Una Message Un MsBuildTask
45. Fase 5 – inserire la variabile Cliccare su “variables” e poi aggiungere una variabile chiamata dbProject
46. Fase 6 – recuperare il nome del database project Configurare la ConvertWorkspaceItem precedentemente configurata Come proprietà input inserire il nome del database project usando il percorso del source control system Es. "$/Demo/NorthwindTest/NorthwindTest.Database/NorthwindTest.Database.dbproj“ Come proprietà Result inserire il nome della proprietà creata precedentemente dbProject Infine inserite Workspace come proprietà workspace Ponete particolare attenzione alla sintassi ricordando sempre che si utilizza la sintassi di VisualBasic Infine configurate l’azione di messaggio inserendo un messaggio tipo “Deploying database “ + dbproject
47. Fase 7 – effettuare il deploy Per il deploy basta configurare l’azione msbuild La proprietà più importante è CommandLineArguments con la quale si specifica l’istanza, il database e dove creare i file. "/p:TargetDatabase=Northwind" +" /p:""DefaultDataPath=C:rogramFilesicrosoft SQL ServerSSQL10.SQL2008SSQLATA""" +" /p:""TargetConnectionString=Data Source=10.0.0.99ql2008,49160%3Buser=sa%3Bpassword=pa$$w0rd""" +" /p:DeployToDatabase=true“ Inserite nella proprietà LogFile un nome di file per il logging e nella proprietà LogFileDropLocation il valore logFileDropLocation Come outDir il valore BinariesDirectory Come Project il valore del progetto, contenuto nella variabile dbProject Come Targets il valore New String() {“Deploy”} con il quale si specifica il target che si vuole eseguire nel progetto database
49. Primo step completato Tramite questa configurazione si è modificata la build aggiungendo il deploy del database project qualora i test e la compilazione fossero ok Il prossimo passo è modificare il web.config dell’applicazione e far puntare IIS del web server di tset ai compilati della build corrente
50. Fase 1 – Custom Action Creare un progetto di tipo ClassLibrary Aggiungere due Code activity, IISChangePhisicalDir e XmlPoke Creare un altro progetto classlibrary dove creare due classi XmlFunctions e IISManagerService Copiare il codice fornito nell’esempio nelle varie classi Aggiungere un progetto Workflow console application
51. Fase 2 – un piccolo test Testare le azioni all’interno del workflow1.xaml creato nel progetto console workflow per verificare che tutto funzioni correttamente. Provare ad esempio con un file xml di test l’azione xmlPoke che modifica parte dell’xml
52. Fase 3 – il web server Nel web server dovreste trovarvi il risultato di una delle build precedenti Andate nella cartella dove avete fatto la share della drop folder e localizzate la cartella dove è stata deployata la web application Configurate IIS puntandolo alla cartella suddetta e creare un appPool dedicato con un nome specifico Es. NorthwindTest Verificate che il sito funzioni correttamente
53. Fase 4 – aggiungere le custom action alla build Nella beta 2, per aggiungere le custom action ad un file xaml tramite designer è necessario procedere nel seguente modo Copiare il file della build Es. NorthwindTest.xaml nella cartella del progetto di test WorkflowConsoleApplication creato precedentemente Aggiungere il workflow al progetto Ora è possibile agire tramite designer grafico Quando il file è finito, fare checkout del file nella cartella BuildProcessTemplate, copiare il file modificato e fare checkin
54. Fase 5 – cambiare la directory di un sito IIS da remoto Inserire dopo la azione msbuild che effettua il deploy del database una azione custom di tipo IISChangePhisicalDir Compilare le proprietà, l’unica che merita una spiegazione è la NewFolder che avrà un valore del tipo "C:uildsResultorthWindTestquot; + BuildDetail.BuildNumber + "PublishedWebsitesorthwindTest.Web“ Questo valore viene calcolato sulla base di Dove è stata fatta la share nel web server di test Si aggiunge il numero di build Si aggiunge il path che porta ai compilati.
55. Fase 6 - opzionale Il lab potrebbe considerarsi completato, ma in una situazione di produzione, il web.config nel source control non è eguale a quello che serve al web.server Es. Bisogna cambiare la stringa di connessione al sql server. Aggiungre una variabile chiamata webConfigFile Aggiungere una azione standard “Assign” ed assegnare a quela variabile il valore BuildDirectory + "inariesPublishedWebsitesorthwindTest.Webeb.config“ Aggiungere un azione di messaggio di build in cui si mostra il file che verrà cambiato Aggiungere una azione di tipo XmlPoke e configurarla in modo da cambiare il file web.config nel modo desiderato.
56. Fase 6 – opzionale I valori per xmlpoke sono ad esempio NewValue (Ricordare le doppie virgolette perché siamo in VisualBasic): "metadata=res://*/Model.NortwindContext.csdl|res://*/Model.NortwindContext.ssdl|res://*/Model.NortwindContext.msl;provider=System.Data.SqlClient;provider connection string=""Data Source=localhostql2008;InitialCatalog=Northwind;IntegratedSecurity=True;MultipleActiveResultSets=True""“ Xpath: "/connectionStrings/add[@name='NorthwindEntities']/@connectionString"