Corso di Versioning, Configuration & Document Management
1 like•751 views
Il documento fornisce una panoramica approfondita del versioning, configuration management e document management, evidenziando l'importanza del controllo delle versioni per tracciare modifiche ai file e facilitare la collaborazione tra sviluppatori. Viene presentato un glossario di termini chiave legati a questi processi e vengono descritti strumenti specifici per la gestione della configurazione e dei documenti. Inoltre, vengono trattati concetti come trunk, branch e tag nel workflow di SVN, insieme alle pratiche di gestione della configurazione e ai principali processi coinvolti.
Corso di Versioning, Configuration & Document Management
- 1. Corso di Version, Configuration & Document Management Salvatore Cordiano @parallelit Master in Sviluppo di Applicazioni Web, Mobile e Social Media
- 2. Agenda • Version management • Configuration management • Document management
- 3. Versioning
- 4. Che cos’è il versioning? Il termine è l’abbreviazione del controllo di versione o version control.
- 5. Version control Un programma che tiene traccia delle modifiche ai file ed alle cartelle. ! ! Il controllo di versione è anche noto come: • Source Control Manager (SCM) • Revision Control System (RCS) • Version Control System (VCS)
- 6. Perché usare il controllo di versione? Perché questo fa schifo!
- 7. Alcuni esempio di software per il controllo di versione • CVS • SVN! • Git! • Mercurial • Bazaar Darcs • Perforce • Fossil • BitKeeper ! Nel corso della lezione faremo principalmente riferimento ad SVN http://subversion.apache.org/
- 8. Quali sono i vantaggi dell’uso di un sistema di controllo delle versioni? • Fornisce supporto alla memorizzazione dei codici sorgenti. • Fornisce uno storico di ciò che è stato fatto. • Può fornire un modo per lavorare in parallelo su diversi aspetti dell’applicazione in sviluppo. • Può fornire un modo per lavorare in parallelo senza intralciarsi a vicenda.
- 9. Il numero di versione (1) • Le modifiche su file e cartelle sono identificate incrementando un numero o un codice associato, denominato “numero di versione”, “etichetta di versione”, o semplicemente “versione”. • Ad ogni versione è associato un’etichetta che identifica il nome della persona che ha apportato la modifica.
- 10. Il numero di versione (2) • Head: identifica l’ultima revisione del repository. • Base: identifica l’ultimo aggiornatamento della copia di lavoro. • Committed: identifica l’ultima revisione in cui un elemento ha subito modifiche.
- 11. Che tipo di file? • Testo • Grafica • Binario • Qualunque
- 12. Glossario (1) • Repository: Il repository è dove i file sono memorizzati, spesso su un server. • Commit: un commit si effettua quando si copiano le modifiche fatte su file locali nel repository (il software di controllo versione controlla quali file sono stati modificati dall'ultima sincronizzazione). • Change: una modifica (change) rappresenta una specifica modifica ad un documento sottoposto al controllo di versione. La granularità delle modifiche considerate come cambiamenti varia tra i sistemi di controllo versione. • Change list: su molti sistemi di controllo versione con commit di modifiche multiple atomiche, una changelist identifica un insieme di changes fatti in un singolo commit.
- 13. Glossario (2) • Check-out: un check-out effettua una copia di lavoro dal repository (può essere visto come l’operazione inversa dell’importazione). • Update: un update copia le modifiche fatte sul repository nella propria directory di lavoro (può essere visto come l’operazione inversa del commit). • Merge: un merge o integrazione unisce modifiche concorrenti in una revisione unificata. • Revision (o versione): è una versione in una catena di modifiche. • Revert: annulla ogni modifica locale a file e cartelle.
- 14. Glossario (3) • Conflict: un conflitto si presenta quando diversi soggetti fanno modifiche in contemporanea alla stessa porzione di un documento. • Resolve conflict: l’intervento di un utente per la risoluzione di un conflitto tra modifiche differenti di uno stesso documento.
- 15. Concetti di base Repository! • Un posto dove memorizzare i sorgenti. • Tipicamente si trova su una macchina remota affidabile e sicura. • Tutti gli sviluppatori condividono lo stesso repository. ! Working folder! • Cartella di lavoro. • Ogni sviluppatore ne ha una collocata sulla propria macchina. • Contiene una copia del codice sorgente relativo al progetto.
- 16. Repository = Time machine • Il Repository è un archivio di ogni versione di ogni file di codice sorgente. • Contiene la storia del progetto. • Rende possibile navigare indietro nel tempo e recuperare versioni vecchie dei file • Capire perché sono state fatte certe scelte e chi le ha fatte. • Capire perché sono stati introdotti nuovi bug e chi li ha introdotti.
- 17. Quando viene rilevato un conflitto? • Sui sorgenti quando: due sviluppatori modificano la stessa linea di codice; il primo fa un commit, il secondo un update e rileva il conflitto. • Sulla struttura dei file/direttori quando: due sviluppatori rinominano/spostano lo stesso file/ direttorio.
- 18. SVN WorkFlow
- 19. Trunk, branch, tag (1)
- 20. Trunk, branch, tag (2) Un modo ragionevole per organizzare un repository è fare in modo che contenga: • Un tronco principale di sviluppo: Trunk • Un luogo dove memorizzare le linee di sviluppo alternative: Branch, Branches • Un luogo dove memorizzare le release stabili: Tag, Tags
- 21. Branch (1) • Relativamente ad un progetto, un branch è una linea di sviluppo indipendente dalle altre. • Viene inizialmente generato come copia completa e condivide parte della storia.
- 22. Branch (2) • I Branch, ad esempio, consentono di iniziare lo sviluppo di una nuova release quando la precedente è ancora in fase di consolidamento. • Una volta terminato il consolidamento è possibile effettuare il merge fra il branch ed il trunk. • Il bug risolti in fase di consolidamento saranno fusi insieme alle modifiche apportate per incorporare le funzionalità della nuova release.
- 23. Tag • Tag = Release • Viene memorizzato separatamente in modo da avere a portata di mano tutti i sorgenti relativi ad una certa release. • In questo modo non è necessario andare a ripescare dal main trunk i sorgenti andando indietro con le versioni dei file.
- 25. A cosa serve il CM? • Ma il sistema funzionava ieri, cosa è accaduto? • Non riesco a riprodurre il problema (bug) sulla mia copia di sistema
- 26. Tre problemi “classici” di CM • Doppia manutenzione Impedire l’esistenza di copie multiple dello stesso file da aggiornare in modo indipendente • Dati condivisi Permettere a due o più sviluppatori di accedere agli stessi file/dati • Aggiornamento simultaneo Impedire il “clobbering” quando due o più sviluppatori modificano lo stesso file
- 27. Configuration management (1) • Identifica e tiene traccia di tutti gli elementi rilevanti della configurazione del sistema, affinché tutti gli errori possibili vengano individuati e vengano trovate le possibili soluzioni.
- 28. Configuration management (2) CM is the practice of handling changes systematically so that a system maintains its integrity over time.
- 29. Configuration management • La configurazione è definita come l’insieme delle caratteristiche funzionali e fisiche di un prodotto stabilite nei documenti tecnici e realizzate nel prodotto stesso. • Il configuration management si occupa di gestire e controllare la variazione di tali caratteristiche. • Non costituisce un’attività opzionale.
- 30. Configuration item Il configuration item (CI) è un unità di configurazione che può essere gestita individualmente. Ad esempio in riferimento ad un’infrastruttura IT un CI può essere un server, un software, un router, etc.
- 31. Configuration management database • E’ un elemento chiave del processo di CM • Viene utilizzato per tracciare tutte le CI e le relazioni tra di loro (Ad esempio: sul server X è disponibile il sistema operativo Y, etc.).
- 32. Principali processi del configuration management • Pianificazione: include le strategie, policy, obiettivi, ruoli e responsabilità nel processo di Configuration Management. Altro elemento da tenere presente nella pianficazione è la struttura del CMDB. • Identificazione: include la selezione, identificazione e “labeling” delle CI. • Controllo: include il processo di assicurare che solo le CI autorizzate siano presenti nel CMDB. Tutto le CI possono essere modificate solo attraverso il processo di change management. • Status Accounting: la gestione del ciclo di vita delle CI. Si occupa del tracciamento e del reporting delle informazioni sullo stato dei CI. • Verifica: include gli audit effettuati con lo scopo di verificare l’accuratezza del CMDB.
- 33. I tool di CM (1) • Sono tool di IT automation che fanno un sacco di lavoro. • I tool di Configuration Management leggono le configurazioni a partire da un file sorgente ed applicano le stesse su uno o più server, in modo automatico, prevedibile e idempotente. ! Idempotente: posso applicare la stessa operazione più volte senza avere effetti “collaterali”.
- 34. I tool di CM (2) inizio configurazione 1. assicurati che apache2 sia installato 2. assicurati che php5 sia installato 3. assicurati che mysql sia installato fine configurazione
- 35. Alcuni esempi di tool di CM • Puppet • Chef • CFEngine • Bcfg2 • BMCBladelogic
- 37. Cosa intendiamo per document management? • Generalmente si fa riferimento al sistema di gestione di documenti o document management system (DMS). • E’ una categoria di sistemi software che serve a organizzare e facilitare la creazione collaborativa di documenti e di altri contenuti. • Tecnicamente il DMS è un’applicazione che si occupa di eseguire operazioni massive sui documenti, catalogandoli ed indicizzandoli secondo determinati algoritmi.
- 38. Document management system Dietro un termine apparentemente semplice si cela un ambito complesso: ! ! ! • metadata • integration • capture • validation • indexing • storage • retrieval • distribution • security • signature • workflow • collaboration • versioning • publishing • reproduction
- 41. Alcuni esempi di DMS • Alfresco • LogicalDOC
- 42. Bibliografia • Wikipedia • http://svnbook.red-bean.com/ • http://subversion.apache.org/ • http://www.di.unipi.it/~cardillo/labso/files/docs/svn- book.pdf