Application Lifecycle Management. Software Configuration. Fabrizio Morando Application Development Manger Microsoft Italia

Application Lifecycle Management Software Configuration Fabrizio Morando Application Development Manger Microsoft Italia

Application Lifecycle Management Ottimizzazione e gestione del ciclo di vita del software Do your systems talk business? 2

Cosa significa Application Lifecycle Management? Il coordinamento della attivita del Ciclo di Vita dello Sviluppo software come: la gestione dei requisiti, la creazione di modelli, lo sviluppo di codice, la build del software, il test dei prodotti. Do your systems talk business? 3

Cosa significa Application Lifecycle Management? Coordinamento attivita possibile attraverso: 1) Un processo che le guidi. Do your systems talk business? 4

Cosa significa Application Lifecycle Management? Coordinamento attivita possibile attraverso: 2) La gestione delle relazioni tra gli attori e gli artefatti di sviluppo prodotti. Do your systems talk business? 5

Cosa significa Application Lifecycle Management? Coordinamento attivita possibile attraverso: 3) Un real-time reporting sui progressi di tali attivita. Do your systems talk business? 6

Persone, Processi e Strumenti Individui Team Organizzazioni Aumento della complessita Orientamento alla Qualita Cultura dell Innovazione Collaborazione Transparenza Integrazione Chiarezza Allineamento Efficienza Integrazione Collaborazione Semplicita Estensibilita Do your systems talk business? 7

Fondamentali dello sviluppo software Collaborazione Predicibilita Processi Qualita Reportistica Testing Do your systems talk business? 8

AREE DI ALM Software Testers & Developers Dev Leads & Developers Issue Managers & Project Managers Configuration & Project Managers Build Managers & Developers Do your systems talk business? 9

Application Lifecycle Management Software Configuration Management Do your systems talk business? 10

Parallel Development Ogni progetto software, qualunque dimensione di team o complessità del sistema questi comporti, richiederà invariabilmente degli effort per condurre parte degli sviluppi in parallelo E necessario sviluppare e mantenere release multiple, o supportare differenti piattaforme. La pratica del Parallel Development aiuta ad incrementare sensibilmente la produttività e il coordinamento del team di sviluppo La domanda non dovrebbe dunque discutere se abilitare una metodologia di parallel development, ma come abilitarla. Do your systems talk business? 11

Sviluppi paralleli usando le branch Il Branching è una tecnica diffusa utilizzata in molti applicativi di version control (VC) per gestire lo sviluppo parallelo. Nella sua forma più semplice, il branching consente lo sviluppo in più di un percorso per uno specific file o gruppo di files Serial Development per il file prog.c Quando viene creata una branch, il contenuto della linea di codice che funge da branchpoint è lo stesso della prima versione della sua branch appena creata. Da quel momento, le due line di sviluppo avranno contenuto differente ed evolveranno in modo separato e isolato l una dall altra. Nuova Branch per il file prog.c Do your systems talk business? 12

Sincronizzazione di linee di sviluppo parallele utilizzando il Merge Il Merging è l azione con cui viene sincronizzato il contenuto di una linea di sviluppo con un altra. Quando si effettua il merging da una child branch verso la sua parent branch, il contenuto dell ultima versione della child viene riconciliato con il contenuto dell ultima versione della parent branch Merge nella parent branch per il file prog.c I contenuti dei due file vengono riuniti in una nuova revisione che risolve opportunamente gli eventuali conflitti tra le due linee di sviluppo venutisi a creare dal momento del branchpoint Do your systems talk business? 13

Branches e Codelines In generale, quando una branch corrisponde a una linea di sviluppo che contiene (o dovrà contenere) più set di modifiche, possiamo definire questa branch come codeline. In teoria, i termini branch e codeline possono essere usati come sinonimi, anche se piu correttamente dovremmo pensare alla codeline come al concetto e alla branch come la sua implementazione. Do your systems talk business? 14

Merging, Propagating, e Syncing Merging è il processo di integrazione delle revisioni di una codeline in un altra determinata codeline. Per esempio un bug fix in una codeline di maintenance potrebbe risultare necessaria nella corrispondente codeline di sviluppo, per poi generare la successiva release-branch. Questo meccanismo è definito change-propagation, o semplicemente Propagation. Quando l intero contenuto di una codeline viene integrato in un altra codeline, o nel workspace degli sviluppatori, questo tipo di attività di merging viene definito syncing with the codeline, o semplicemente syncing. Do your systems talk business? 15

Version Tree Diagrams Nel disegnare codelines, branches, change-tasks, e le relazioni tra di essi, si utilizza una struttura ad albero con nomi di branch in rettangoli e nomi di versione in cerchi ( box o circles senza nomi interni sono considerati anonimi). Branch e Codelines sono rappresentate con linea continua, laddove merge e propagations sono rappresentate con linee tratteggiate. Nuova Branch per il file prog.c Do your systems talk business? 16

Mainline Model Identificando il concetto di codeline partendo dalla definizione di linea di codice come un insieme di files di codice sorgente necessari per produrre il software in oggetto, vorremmo introdurre uno dei modelli più efficaci e allo stesso tempo di più semplice Il Mainline Model parte infatti dal concetto di Mainline come linea di codice principale, alla quale giungono tutte le modifiche effettuate, e dalla quale si diramano tutte le altre codelines, ognuna con il suo proprio obbiettivo e proposito di evoluzione. Do your systems talk business? 17

Mainline In un mondo ideale non ci sono bugs, non ci sono vincoli temporali, lo scheduling non viene mai disatteso, ogni release contiene features che funzionano perfettamente, gli utenti finali effettuano tutti contemporaneamente l upgrade alla nuova versione. Nel mondo ideale ad ogni fase di sviluppo corrisponde una precisa release, che sarà l unica realtà del nostro prodotto durante tutta la fase di sviluppo della release successiva, e così via. In un mondo ideale non avremmo bisogno di tecniche di SCM, sarebbe sufficiente una sola linea di codice, la nostra Mainline. Do your systems talk business? 18

Parallel Codelines Nel mondo reale però ci si deve scontrare con differenti realtà. Dobbiamo tenere presente che una release può richiedere manutenzione successiva al rilascio, bugfixing, e spesso le tempistiche di rilascio possono sovrapporsi all inizio di una nuova fase di sviluppo. E quindi evidente la necessità di congelare una determinata versione del prodotto, ed eventualmente lavorare ed evolvere il prodotto stesso, o alcune parti di esso, in maniera isolata rispetto ai nuovi sviluppi in corso d opera. Nel nostro modello, utilizziamo due tipologie di Codelines: Release Codelines Developement Codelines Do your systems talk business? 19

Release Codelines La prima evidenza è quindi rappresentata dall introduzione di nuove branches ai fini del rilascio. Queste si definiscono appunto Release Codelines. In questo modo, effettuando una branch completa della mainline di codice sorgente, e possibile parallelizzare le attività della nuova fase di sviluppo con le attività di stabilizzazione della versione in fase di rilascio. Un altra evidenza è data dalla possibilità di intervenire in bugfixing sul codice già rilasciato, lavorando sulla release codeline opportuna, senza impattare sugli sviluppi in corso sulla mainline. Do your systems talk business? 20

Development Codelines L esigenza di poter isolare gli sviluppi e le modifiche su codeline differenti introduce invece il concetto di Development Codelines. E possibile in questo modo lavorare su differenti parti del sistema in modo isolato, garantendo la consistenza della mainline, sulla quale vengono integrate le codelines di sviluppo giunte a code complete. Questa metodologia rende possibili gli sviluppi di singole features restano svincolati tra loro, quindi cicli di test e stabilizzazione sovrapposti e più ravvicinati, e consente anche il rilascio più frequente delle preview del prodotto con le features già disponibili Do your systems talk business? 21

Il flusso delle modifiche lo scopo primario della mainline è quello di contenere codice sufficientemente completo per il ciclo di stabilizzazione, per cui il suo grado di stabilità è necessariamente vincolato dalla stabilità introdotta dalle codelines di sviluppo integrate. Le modifiche fluiscono continuamente dalle release codelines nella mainline. Ogni qualvolta che viene corretto un bug in un release codeline, la modifica viene integrata nella mainline. Questo non compromette la mainline, in quanto le bugfix introdotte nelle release codelines sono già testate Do your systems talk business? 22

Il flusso delle modifiche (2) Le release codelines non vengono mai integrate dalla mainline. Questo per il motivo di stabilità e criticità della release codeline stessa C è un flusso costante di modifiche anche tra Mainline e Development Codelines. A doppio senso, in questo caso. Una Development Codeline è fortemente instabile e gran parte del tempo della sua vita potrebbe anche non essere build-abile. Per questo motivo, il flusso contrario di integrazione, dalla Development alla Mainline, dovrebbe invece avvenire solo al completamento dello sviluppo e stabilizzazione della feature sulla Development Codeline. Do your systems talk business? 23

BRANCHING STRATEGY SAMPLE Branch Branch Branch Branch RI FI RI RI RI Branch DEV FT3 V2.0 FT3 (start) V2.0 FT3 8 The DEV branches are created to isolate feature development. V2.0 FT2 (start) V2.0 FT2 DEV FT2 6 DEV FT1 V2.0 FT1 (start) V2.0 FT1 4 Using MAIN as an integration codeline, with test/production ready integrated artifacts. V1.0 V2.0 FT1 V2.0 Golden MAIN 1 2 2 2 3 5 9 V1.0 VSS V1.0 (Release) V1.0.1 V2.0 (RTM) (Initial base) PRODUCTION 7 V1.0.1 (hotfix) Do your systems talk business? 24

RI Branch RI Branch STABILIZING E ON-THE-FLY CR MANAGEMENT BRANCHING STRATEGY. Automatred non regression TEST execution + V2.0 FT 4 specific tests Bugfix 2.0.1 Bugfix 2.0.2 Bugfix 2.0.3 V2.0 (RTM) V 2.0 (PROD) 3 MAIN V2.0 (Release Candidate) 1 V2.0 Golden 4 DEV FT 4 2 V2.0 FT 4 Do your systems talk business? 25

Application Lifecycle Management SCM con Team Foundation Server Do your systems talk business? 26

Visual Studio 2010 Do your systems talk business? 27

IntelliTrace UML Modeling Architecture Explorer Logical Class Designer Load Testing UI Test Automation Performance Profiling Code Coverage Database Change Mgmt Database Unit Testing Silverlight Tools SharePoint Development Web Development Generate from Usage New WPF Editor Test and Lab Manager Test Case Management Manual Testing Test Record & Playback Layer Diagram Web Testing Test Impact Analysis Static Code Analysis Code Metrics Database Deployment Test Data Generation Multi-core Development Cloud Development Windows Development Office Development Customizable IDE Do your systems talk business? 28

Team Foundation Server Team Foundation Server At a Glance Process Focused Process Templates SharePoint Customizable Version Control Integrated Check-in Check-in Policies Shelving Work Item Tracking Manage work Bugs, Tasks, Requirements, Stories, Risks, etc. Very Extensible Build Automation Continuous Integration Scheduled Ad Hoc Reporting Decision Support Track Project Progress Do your systems talk business? 29

At a Glance - TFS Version Control Changesets Check-in Policies Shelving Branching & Merging Logical container of data related to check-in Requirements for Check-in Set aside pending changes Path-space, configurationbased Do your systems talk business? 30

2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.