Application Lifecycle Management Software Configuration - Fabrizio Morando Application Development Manger Microsoft Italia
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
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’ Collaborazione Chiarezza
Orientamento alla Qualita’ Transparenza Allineamento
Cultura dell’Innovazione Integrazione Efficienza
• Integrazione • Semplicita’
• Collaborazione • Estensibilita’
Do your systems talk business? | 7
Fondamentali dello sviluppo software
Predicibilita’
Collaborazione Processi
Qualita’ Reportistica Testing
Do your systems talk business? | 8
AREE DI ALM
Software Testers Dev Leads Issue Managers Configuration Build Managers
& & & & &
Developers Developers Project Project Managers Developers
Managers
Do your systems talk business? | 9
Application Lifecycle
Management
Software Configuration
Management
Do your systems talk business? | 10Parallel 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? | 11Sviluppi 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? | 12Sincronizzazione 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? | 13Branches 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? | 14Merging, 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? | 15Version 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? | 16Mainline 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? | 17Mainline
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? | 18Parallel 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? | 19Release 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? | 20Development 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? | 21Il 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? | 22Il 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? | 23BRANCHING STRATEGY SAMPLE
V2.0 FT3
The DEV
DEV FT3 8 branches are
created to
V2.0 FT3 (start) isolate feature
development.
V2.0 FT2 (start) V2.0 FT2
DEV FT2 6
RI
Using MAIN as an
integration codeline, with
V2.0 FT1 test/production ready
V2.0 FT1 (start)
integrated artifacts.
RI
DEV FT1 4
FI
Branch
Branch
Branch
RI
V1.0 V2.0 FT1 V2.0 Golden
MAIN 1 2 2 2 3 5 9
V1.0
Branch
Branch
RI
VSS V1.0 (Release) V1.0.1 V2.0 (RTM)
(Initial base) PRODUCTION 7
V1.0.1 (hotfix)
Do your systems talk business? | 24STABILIZING 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
Branch
Branch
RI
V2.0 Golden
V2.0 (Release Candidate)
MAIN 1 4
RI
V2.0 FT 4
DEV FT 4
2
Do your systems talk business? | 25Application Lifecycle
Management
SCM con Team Foundation
Server
Do your systems talk business? | 26Visual Studio 2010
Do your systems talk business? | 27Test and Lab Manager
IntelliTrace™ Test Case Management
UML Modeling Manual Testing
Architecture Explorer Test Record & Playback
Logical Class Designer Layer Diagram
Load Testing Web Testing
UI Test Automation Test Impact Analysis
Performance Profiling Static Code Analysis
Code Coverage Code Metrics
Database Change Mgmt Database Deployment
Database Unit Testing Test Data Generation
Silverlight Tools Multi-core Development
SharePoint Development Cloud Development
Web Development Windows Development
Generate from Usage Office Development
New WPF Editor Customizable IDE
Do your systems talk business? | 28Team Foundation Server At a Glance
Team Foundation Server
Process Focused
Version Control
Process
Templates Work Item Tracking
Integrated
SharePoint Check-in Build Automation
Manage work
Customizable Check-in Reporting
Bugs, Tasks, Continuous
Policies
Requirements, Integration
Shelving Stories, Risks, Decision
Scheduled Support
etc.
Ad Hoc Track Project
Very Extensible
Progress
Do your systems talk business? | 29At a Glance - TFS Version Control
Check-in Branching &
Changesets Shelving
Policies Merging
• Logical • Requirements • Set aside • Path-space,
container of for Check-in pending configuration-
data related changes based
to check-in
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.Puoi anche leggere
