La gestione delle configurazioni(Software configuration management)

Prof. Paolo CiancariniCorso di Ingegneria del SoftwareCdL Informatica Università di Bologna

Obiettivi di questa lezione• Cos’è il Software Configuration Management (SCM)?• Attività tipiche del SCM• Strumenti per SCM

30 3

Sviluppare iterativamente

Controllare le modifiche

Usarearchitetture

di componentiGestire irequisiti

Modellaregraficamente

Verificarela qualità

Principi guida dello sviluppo software

Come gestire il ciclo di vita del sw?

• Come si gestisce lo sviluppo delle varie versioni?

• Come si identificano i diversi componenti di un sistema software?

• Cosa si registra di ogni deployment?• Come si tracciano i cambiamenti delle versioni

e configurazioni operative?

4

Le configurazioni dei sistemi software

• Il problema:• Ogni sistema software cambia durante lo sviluppo, e anche dopo• Esistono contemporanemente più versioni del sistema:

• Modifiche da persone diverse• Varianti diverse rilasciate a clienti diversi• Nuove versioni in sviluppo• Deployment su hw e sistemi operativi diversi

➭ Come si controlla lo sviluppo delle modifiche e delle versioni?

• Soluzione: Software Configuration Management

Un esempio di toolchain basata su SCM (DevOps)

DevOps è un metodo moderno di gestione degli sviluppi (Developments) in parallelo con le Operations. Si basa sull’idea di integrazione continua (continuous integration)

Esempio: Integrazione continua in XP• Mantieni un repository condiviso del codice • Automatizza le build e rendile auto-testanti• Tutti gli sviluppatori possono eseguire commit alla baseline tutti i giorni• Ogni commit fa partire una build: fail fast, ovvero se un commit di uno

sviluppatore è tale da far fallire un test, bisogna intervenire immediatamente prima che si crei una valanga di errori successivi

• Fai in modo che il build sia veloce• Esegui i test in un clone dell'ambiente di produzione• Fa’ in modo che sia facile prendere le ultime versioni dei pacchetti• Ognuno può vedere i risultati dell'ultimo build• Automatizza il deployment: anche il rilascio del software sugli ambienti di test o

sull'ambiente di produzione deve essere automatizzato.

Versioni: esempi

• V0: file vuoto• V1: prima stesura• V2: iterazione al posto della ricorsione• V3: aggiunta documentazione• V4: risolti tutti i bug• V5: risolto altro bug

Storia (oppure log)

Commit

Si fa commit quando si associa un nome ad una versione, inserendo il file in un repositoryCheck IN: inserimento file nel repositoryCheck OUT: aquisizione file in mutua esclusione

Branch

Un branch è una sequenza di versioni

Nell’esempio in figura, la versione principale (trunk) è in verde, i branch in gialloIl grafo delle versioni non è un albero a causa dei merge (frecce rosse)

Configurazione: esempio

Supponiamo di avere creato un programma su più moduli e più versioni• Main.c 1.25, 2.12• Cli.c 1.16• Gui.cpp 1.13• Makefile 1.4• Foo.c 1.1, 2.7

Occorrerà poter fare commit di intere directory (CVS)

Versioni e configurazioni

CVS (Grune, 1986)

Cos’è la gestione delle configurazioni sw (SCM)?

• Definizione: Software Configuration Management• Insieme delle attività del processo di sviluppo che costruiscono

una baseline di un sistema software• Include i metodi e le tecniche per iniziare, valutare e controllare

la modifica ad un sistema software

• Standard (approvati da ANSI)• IEEE 828: Software Configuration Management Plans• IEEE 1042: Guide to Software Configuration Management

Gestire il SCM

• SCM è la funzione che ha lo scopo di rendere efficiente la gestione tecnica dei rilasci

• L’ambito di applicazione di SCM può essere:• A livello aziendale (tutti i progetti sw di un’azienda)• Per un singolo progetto• Distribuito tra i membri del team di progetto• Un mix dei tre approcci precedenti

Principali attività di SCM

• Identificazione degli elementi sw in configurazione• Modellazione del sistema e dei suoi componenti in evoluzione

• Promotion management• Gestione di versioni per altri sviluppatori

• Gestione dei rilasci• Gestione di versioni per clienti e utenti

• Change management • Approvazione e tracciamento di richieste di modifica

• Gestione dei branch• La gestione dello sviluppo simultaneo da più persone

• La gestione delle varianti• La gestione di versioni coesistenti

Ruoli importanti per SCM

• Configuration manager• Ruolo responsabile di identificare i configuration item• Definisce le procedure per creare promozioni e rilasci

• Membro del Change Control Board• Approva o respinge le richieste di modifica

• Sviluppatore• Crea promozioni durante lo sviluppo o su richiesta di modifica.

Inserisce modifiche e risolve conflitti• Auditor

• Sceglie e valuta le promozioni per il rilascio e assicura consistenza e completezza di ogni rilascio

Terminologia

• Termini da definire:• Configuration item• Baseline• SCM Directories• Versione• Revisione• Rilascio

➭ Seguiamo lo standard IEEE 828-2012

Terminologia: Configuration Item

Configuration Item (elemento in configurazione):Collezione di artefatti (documenti e software), messi in configurazione cioè trattati come singola entità nel processo di gestione delle configurazioni

• Un configuration item contiene non solo codice sorgente ma tutti gli artefatti rilevanti, di vari tipi

• In certi progetti metteremo in configurazione non solo pezzi di software ma anche hardware (es. tipo di CPU, schede di rete, frequenze di bus, ecc)

Esempi di configuration item

Definire gli elementi in configurazione

• Non tutti gli artefatti prodotti durante il ciclo di vita verranno messi in configurazione

• Due problemi:• Cosa: Selezione dei configuration item

• Cosa va messo sotto controllo di configurazione?• Quando: Quando iniziamo a porre un elemento sotto controllo

di configurazione?• Dilemma:

• Iniziare troppo presto a porre elementi in configurazione aumenta la “burocrazia” di progetto e i costi

• Iniziare troppo tardi genera caos

Possibiliconfiguraton item

Modelli Sottosistemi Documenti

Modello oggetti Modello dinamico

Database User Interface

. . . .

Codice Dati Test di unità

RAD ODD

. . . . . . . .

. . . .

“il progetto”

Possibili elementi della configurazione

Artefatti per SCM: quali scegliere?

• Descrizione del problema• Software Project Management

Plan (SPMP)• Documento Requirements

Analysis (RAD)• Documento System Design

(SDD)• Contratto del progetto• Documento Object Design

(ODD)• Modello dinamico• Modello degli oggetti• Modello funzionale• Test di unità• Strategia di integrazione

• Codice sorgente• Specifica API• Dati e database in input • Test plan• Test data• Support software (parte del

prodotto)• Support software (al di fuori

del prodotto)• Manuale utente• Manuale amministratore

Possibili scelte per SCM (in rosso)

• Descrizione del problema• Software Project Management

Plan (SPMP)• Documento Requirements

Analysis (RAD)• Documento System Design

(SDD)• Contratto del progetto• Documento Object Design

(ODD)• Modello dinamico• Modello degli oggetti• Modello funzionale• Test di unità• Strategia di integrazione

• Codice sorgente• Specifica API• Dati e database in input • Test plan• Test data• Support software (parte del

prodotto)• Support software (al di fuori

del prodotto)• Manuale utente• Manuale amministratore

Terminologia: versione

Versione: Il rilascio iniziale o conseguente di un configuration item associato ad una sua ricompilazione completa (build)

Nota: versioni diverse possono offrire diverse funzionalità

Terminologia: Baseline

Baseline: Un artefatto revisionato e approvato formalmente dal management, utile per ulteriori sviluppi, e che può essere modificato solo mediante procedure controllate

L’obiettivo di una baseline è di ridurre il rischio di modifiche senza controlli durante il ciclo di vita (dunque non solo durante lo sviluppo)

Esempi: •Baseline A: La API è completamente definita; i corpi dei metodi sono vuoti

•Baseline B: Tutti i metodi di accesso sono stati implemementati e testati

•Baseline C: Anche la GUI è stata implementata.

Baseline

http://blog.feabhas.com/tag/baseline/

Una "baseline" è la descrizione, ad un certo punto del tempo, di un sistema sw e dei suoi componenti, che serve come riferimento per definire una modifica del sistema stesso

Dare nome alle baseline

• Esistono molti schemi di denominazione di baseline (esempi: 1.0, 6.01a, ...)

• Molto comune uno schema a tre cifre:

Principale, Rilascio esterno

(cliente)

Secondaria,Rilascio interno(sviluppatore)

Piccola revisione (sviluppatore)

7.5.5

Tipi di baseline

• Un sistema software evolve via via in più baseline, ciascuna prodotta di solito dopo una qualche revisione della precedente

• Es. analysis review, design review, code review, system testing, client acceptance, …• baseline di sviluppo• baseline funzionale• baseline di prodotto

Evoluzione dell’albero delle configurazioni

L’avanzamento del progetto produce artefatti, che vanno in configurazione; esistono alcune baseline/attività tipiche di ogni sviluppo di sistema:1.baseline funzionale per la System Requirements Review (SRR)2.Preliminary Design Review (PDR) per "design-to"3.Critical Design Review (CDR) per "build-to"4.System Acceptance Review (SAR) per "as-built"5.Operational Readiness Review (ORR) per "as-deployed"

Fonte: http://aaq.auburn.edu/node/60

Transizioni tra baseline

Rilascio

Baseline A (sviluppo)

Baseline B (funzionale, prototipo 1)

Baseline C (prodotto, beta test)

Come gestiamo le modifiche nelle baseline?

=> Change Management

Tempo

Change management

• “Change management” è la gestione delle richieste di modifica delle baseline

• Processo di change management: • Richiesta di modifica (da parte di qualche stakeholder)• Si valuta la richiesta rispetto ai requisiti ed ai vincoli di progetto• In seguito a tale valutazione la richiesta viene accettata o rifiutata• Se accettata, la modifica si assegna ad uno sviluppatore e

realizzata• La modifica realizzata viene ispezionata (audited)

User

ReleaseSoftware

RepositoryMaster

DirectoryProgrammer

Promotion

Controllo delle modifiche

• Due tipi di controllo delle modifiche:• Promozione: cambia lo stato del codice internamente al

progetto• Rilascio: Un software modificato viene pubblicato all’esterno

dell’organizzazione che lo sviluppa

Foo ’16 Foo ’17

Directory tipiche di SCM

• Programmer’s Directory • (IEEE Std: “Dynamic Library”)• La controlla il programmatore

• Master Directory • (IEEE Std: “Controlled Library”) • directory centrale delle promozioni

• Software Repository• (IEEE Std: “Static Library”)• Codebase delle baseline rilasciate

Archivio centraledel sorgente

Rilascio

Promozione

Principali strumenti per SCM• RCS (Revision Control System) [Tichy 1982] : il primo • CVS (Concurrent Version Control) [Grune 1986]:

• Basato su RCS, permette sviluppi concorrenti senza lock• http://www.cvshome.org/

• Subversion [Collabnet 2004]:• Basato su CVS, open source• http://subversion.tigris.org/

• Git [Torvalds 2005]:• visualizzare e navigare una cronologia di sviluppo non lineare• Ipotesi: una modifica verrà fusa più spesso di quanto sia scritta• GitHub [2008]: social hosting di versioni e configurazioni

Modeling sw Configuration Management

• IEEE model• RCS model• CVS model• SVN model

Modello IEEE

Version*

Controlled Item

*

CM Aggregate ConfigurationItem

ReleasePromotion

RepositoryMaster Directory

*

*

Modello RCS

Version

*

File

Tag

*

*Aggregati proibitiControllo della concorrenza basato su lockNumeri di versione distinguono promozioni e rilasci Le baseline sono identificate da tag

User

locks *

0..1

Repository

*

Working Copy

*

11

ancestor

*1

Numerazione di versioni in RCS

1.1 :Revision

1.3.1.1:Revision

1.3.2.1:Revision

1.2 :Revision 1.3 :Revision 1.4 :Revision

1.3.1.2:RevisionBranch 1.3.1

Branch 1.3.2

Trunk

Modello CVS

Revision

Controlled Item*

Directory File

RepositorySuperset di RCSControllo degli aggregati in directoryModifiche concorrenti con copy/modify/merge(niente locking)

Tag

**

*

*

Working CopyUser

*

11

ancestor

*1

Copy/Modify/Merge in CVS

:Repository

modify()

alice:Developer

checkin(ac)

checkout()

aliceCopy:WorkingCopy

checkout()

joe:Developer

modify()

update(jc)

checkin(jc)

merge(ac)

joeCopy:WorkingCopy

Se le modifiche si sovrappongono, CVS di

Joe risolve i conflitti editando la copia

fusione

Ridenominazione in CVS

• CVS non supporta la ridenominazione• Invece lo sviluppatore

• Ridenomina il file nella copia di lavoro• Rimuove il vecchio nome dal repository• Aggiunge il nuovo nome nel repository

• I due alberi delle versioni sono disconnessi

editor1.3 editor1.4

myEditor1.1

myEditor1.2

cvs remove editor

cvs add myEditor

La relazione tra i due alberi di

revisione è persa

Subversion• Open Source http://subversion.tigris.org/

• Basato su CVS• Subversion interface and features similar to CVS• Commands: checkout, add, delete, commit, diff

• Differisce da CVS• Version controlled moving, renaming, copying of files and

directories• Version controlled metadata of files and directories

• Opzioni• Istallazione standalone• Integrato con Apache webserver

• The time for branch management is independent of the size of the system (CVS creates physical copies of the files, Subversion uses only tags)

Modello Subversion

Revision

Controlled Item*

Directory File

Repository

Simile a CVSControllo del file renaming/movingNumeri di versione globaliBranches e tags sono copie

*

*

Working CopyUser

*

11

ancestor

*1

copy* 1

SVN Global Revision Number Scheme

Il numero di versione globale si applica all’intero alberoIl numero di versione aumenta dopo ogni check in, indipendentemente dalla quantità delle modifiche

Ridenominazione in Subversion

• Subversion vede come atributo il nome di un CI • Le modifiche al nome sono la stessa cosa che modifiche al

contenuto• C’è un unico albero storia• Lo strumento riesce a gestire i conflitti di ridenominazione

editor 3 editor 4 myEditor 5

svn rename editor myEditor

Duplicazione in Subversion

• Subversion traccia le copie così come traccia la ridenominazione• La storia di un CI copiato include la storia dell’originale• Le copie costano poco, vengono memorizzate solo le differenze• I branch sono copie

editor 3 editor 4

myEditor 5

svn copy editor myEditor

editor 6

GIT

• Pro Git: http://www.git-scm.com/book/en/v2

• Creative Commons Attribution Non Commercial Share Alike 3.0 license

Controllo delle versioni centralizzato

Esempio: Subversion

Le versioni sono “delta”

Controllo delle versioni distribuito

Esempio: git

Snapshots

• In questo esempio i file A B C sono tracciati• Il database è conservato su ogni macchina locale• Per editare: “checkout” dal database in working directory• “commit” da working directory nel database• Memorizzato in formato compresso • I file sono memorizzati con hash SHA-1 non con filename

Operazioni locali

A che serve l’area stage?

http://blog.mikepearce.net/2010/05/18/the-difference-between-git-pull-git-fetch-and-git-clone-and-git-rebase/

SCM in SWEBOK

Domande di autotest

• Cos’è una versione?• Cos’è una configurazione?• A che serve un commit?• Come si inizia a usare git?

Letture raccomandate

Chacon e Straub, Pro git, Apress, 2014

Domande?