Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Configuration Management Leonardo Mariani University of Milano Bicocca [email protected] Configuration management Program EVOLUTION Program’ • CM is concerned with managing evolving software systems: – control the costs and effort • procedures + standards • part of the quality process System families HP versio n Deskto p versio n Win dows XP versio n In itial sy stem Server versio n PC versio n Linux versio n Sun versio n from Sommerville “Software Engineering” CM standards • based on a set of standards which are applied within an organisation – how items are identified, – how changes are controlled – how new versions are managed • Standards may be based on external CM standards (e.g. IEEE standard for CM) • Products to be managed – specifications, designs, programs, test data, user manuals… The CM plan • Defines the types of documents to be managed and a document naming scheme • Defines who takes responsibility for the CM procedures and creation of baselines • Defines policies for change control and version management • Defines the CM records which must be maintained • Describes the tools which should be used to assist the CM process and any limitations on their use • Defines the process of tool use • Defines the CM database used to record configuration information Configuration item identification • Large projects typically produce thousands of documents which must be uniquely identified • Some of these documents must be maintained for the lifetime of the software • Document naming scheme should be defined so that related documents have related names • A hierarchical scheme with multi-level names is probably the most flexible approach – PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE Configuration hierarchy PCL-TOOLS COMPILE BIND FORM FORM-SPECS EDIT ST RUCT URES DISP LAY QUERY AST-INT ERFACE FORM-IO OBJECT S CODE MAKEGEN - HELP T EST S from Sommerville “Software Engineering” From A. van Lamsweerde “Requirements Engineering TRACEABILITY Features, revisions, variants • Feature = change unit – functional/non-functional: sets of functional/non-functional reqs – environmental: assumptions, constraints, work procedures, etc • Feature changes yield new system version – revision: to correct, improve single-product version – variant: to adapt, restrict, extend multi-product version => commonalities + variations at variation points space Variant A Revision A1 Revision A2 meeting date (user class A) Variant B Revision B1 Revision B2 meeting date + location (user class B) time A wide variety of changes Cause Change type Version type errors & flaws better understanding new functionality corrective corrective extension extension revision revision revision, variant improved feature ameliorative revision new users/usage adaptative variant other ways of doing adaptative variant new regulation adaptative revision alternative regulation adaptative variant organizational change adaptative revision new priority/constraint adaptative revision Evolution support requires traceability management • An item is traceable if we can fully figure out – WHERE it comes from, WHY it is there – WHAT it will be used for, HOW it will be used • Traceability management (TM), roughy – identify, document, retrieve the rationale & impact of RD items • Objectives of traceability – assess impact of proposed changes – easily propagate changes to maintain consistency TM relies on traceability links among items • To be identified, recorded, retrieved • Bidirectional: for accessibility from – source to target (forward traceability) – target to source (backward traceability) • Within same phase (horizontal) or among phases (vertical) forward Objectives, domain concepts, requirements, assumptions backward horizontal vertical Architectural components & connectors Source code Test data User manual A taxonomy of traceability link types Dependency link Inter-version link Intra-version link Subtype Variant Revision Derivation Use What are the types of links traced by Configuration Management? Inter-version traceability: variant, revision links B has all features of A + specific ones A Variant master variantOf B specific reqs for handling important participants common reqs for meeting scheduling B overrides features of A, adds/removes some, keeps all others A Revision previous reqs for optimal date to fit exclusion constraints + link annotation with configuration management info: date, author, status, rationale next B reqs for optimal date to fit exclusion & preference constraints Our focus: how to (semi-)automating traces inter-version links Intra-version traceability: use, derivation links changing A makes B incomplete, inconsistent, inadequate or ambiguous Use A usedBy reqs for loan management uses B def of what a patron is B is built from A under constraint that A must be met A Derivation B metBy derivedFrom objective of anywhere anytime notification reqs for SMS notification CASE for CM How does it work without CM? Version Management • Have you ever had something like that in you file system? Version Management • or this? ComputeTaxes.java Document.java ComputeTaxes_old.java Good… considered the New bug let’s in release 1!Another Initial There’s aproduce bug, FIX! Aisnew functionality ismore urgently There isneeded inversion… release 1!Fix case ofa abug project with New functionalities It’s time to done, let’s a new Fix Development proceeds efficiently oh no, there’s a bug! Fix! neeeded for rel12and rel2 than 1 file!!!!! produce release release Let’s add another functionality GUI.java ComputeTaxes_rel2.java Document_old.java ComputeTaxes_ver1.java Person_fixed1java Person_rel1.java Document_rel2.java Document_ver1.java ComputeTaxes_ver2.java ComputeTaxes_rel1_FIXED.java Document_rel1_FIXED2_extended.java ComputeTaxes_rel1.java Document_ver2.java Document_rel2_extended.java Person_old.java Document_rel1.java ComputeTaxes_rel1_old.java Person_old.java ComputeTaxes_rel1_FIXED2.java Document_rel1_old.java Document_rel1_FIXED2.java ComputeTaxes_rel2_extended.java ComputeTaxes_rel1_FIXED2_extended.java Coordination • How to coordinate the activity of multiple developers? – Use one PC? – Send emails? – Use a shared folder? General Scenario Single User Scenario produce the initial version Repository ComputeTaxes Single User Scenario Repository commit ComputeTaxes v1.0 ComputeTaxes Single User Scenario extend! Repository ComputeTaxes v1.0 ComputeTaxes Single User Scenario Repository commit ComputeTaxes v2.0 v1.0 ComputeTaxes ComputeTaxes Single User Scenario extend! Repository ComputeTaxes v2.0 v1.0 ComputeTaxes ComputeTaxes Single User Scenario Repository commit ComputeTaxes v3.0 v2.0 v1.0 ComputeTaxes ComputeTaxes ComputeTaxes Single User Scenario First release! Repository ComputeTaxes v3.0 v2.0 v1.0 ComputeTaxes ComputeTaxes ComputeTaxes Single User Scenario First release! Repository cvs tag “rel 1” ComputeTaxes v3.0 – rel 1 v2.0 v1.0 ComputeTaxes ComputeTaxes ComputeTaxes Single User Scenario Extend and produce 2nd release Repository cvs commit v4.0 – rel 2 v2.0 – rel 1 v3.0 v1.0 v2.0 ComputeTaxes v1.0 ComputeTaxes ComputeTaxes ComputeTaxes cvs tag “rel 2” ComputeTaxes Single User Scenario Extend both rel 1 e rel 2 Repository v3.0.1 v2.0 – rel 1 v3.0 v1.0 v2.0 ComputeTaxes v1.0 v5.0 v2.0 v4.0––rel rel12 v3.0 v1.0 v2.0 v3.0 v2.0 – rel 1 ComputeTaxes v1.0 v1.0 v2.0 ComputeTaxes v1.0 ComputeTaxes ComputeTaxes ComputeTaxes … ComputeTaxes Single User Scenario Further develop both branches Repository v3.0.2 v3.0.1 v2.0 – rel 1 v3.0 v2.0 v1.0 v3.0 v2.0 – rel 1 ComputeTaxes v1.0 ComputeTaxes v2.0 v1.0 v1.0 v6.0 v5.0– rel 2 v2.0 v4.0 v3.0 v2.0 v4.0 – rel rel 1 12 v1.0 v3.0 v2.0 –––rel v3.0 v2.0 v1.0 v2.0 rel 11 ComputeTaxes v1.0 v3.0 v2.0 – rel ComputeTaxes v1.0 v2.0 v1.0 v1.0 v2.0 ComputeTaxes v1.0 v1.0 ComputeTaxes ComputeTaxes ComputeTaxes … ComputeTaxes Multi User Scenario Repository commit v1.0 ComputeTaxes v1.0 ComputeTaxes Multi User Scenario Repository v1.0 ComputeTaxes v1.0 cvs checkout ComputeTaxes v1.0 ComputeTaxes Multi User Scenario Repository cvs commit v2.0 ComputeTaxes v2.0 ComputeTaxes v1.0 ComputeTaxes Multi User Scenario When starting a new working session, the user has to execute an update first! Repository v2.0 ComputeTaxes v2.0 ComputeTaxes cvs update v2.0 ComputeTaxes Multi User Scenario Developers work in parallel Repository v3.0 ComputeTaxes v2.0 ComputeTaxes v3.0 ComputeTaxes Multi User Scenario Repository v3.0 ComputeTaxes v3.0 ComputeTaxes cvs commit v3.0 ComputeTaxes Multi User Scenario There is an attempt to overwrite the changes implemented by another developer – operation forbidden!!!! Repository cvs commit v3.0 ComputeTaxes v3.0 ComputeTaxes v3.0 ComputeTaxes Multi User Scenario Repository cvs update v3.0 ComputeTaxes v3.0 ComputeTaxes v3.0 ComputeTaxes v3.0 ComputeTaxes Multi User Scenario Manual resolution of the conflicts Repository v4.0 ComputeTaxes v3.0 ComputeTaxes v3.0 ComputeTaxes v3.0 ComputeTaxes v3.0 ComputeTaxes Multi User Scenario Repository cvs commit v4.0 ComputeTaxes v4.0 ComputeTaxes v3.0 ComputeTaxes Structure of the Repository Revisions • A same file occurs in multiple revisions file1.dat 1.1 1.2 1.3 file2.dat 1.1 1.2 1.3 file3.dat 1.1 1.2 1.3 1.4 1.4 1.5 Structure of the Repository Versions • A coherent and consistent collection of files existing at a given time might be relevant – Versions identify these collections of files – Each version has a name (tag) file1.dat 1.1 file2.dat file3.dat 1.2 1.1 1.1 1.2 app-rel-1-0 1.3 1.2 1.3 1.3 1.4 app-rel-2-0 Structure of the Repository Branches • A project is usually organized into multiple development branches – The main branch is usually called head or trunk or master – Branches can be created and merged Branching file1.dat 1.2 1.1 1.3 1.2.2.1 1.4 1.2.2.2 1.2.2.3 Merging 1.3 1.2.2.2 1.4 1.2.2.3 1.5 1.6 1.2.2.4 (free) Tools CVS CVS • CVS = Concurrent Version System – To trace versions of documents (and files), and – To support concurrent and distributed activity • File (revision) • Module (version) • Repository • Working/local copy Main Commands: • • • • • • CVS CVS CVS CVS CVS CVS init import checkout update add commit • • • • CVS CVS CVS CVS passwd log diff tag Configuring a CVS Server Server-side operations 1. create the repository – cvs –d <repository_folder> init – cvs –d /home/cvsRepository init Structure of the repository <repository_folder> CVSROOT modules passwd 2. create the users – Edit the file passwd 3. Acticate the CVS service ... <module1> <module2> ... <modulen> CVSROOT • String (environment variable or command argument) that includes the information necessary to access a CVS repository • :<protocol>:<connection data>:<cvsroot path> Examples • Access to a remote server :pserver:<usr>@lta.disco.unimib.it:/home/cvsIngSw ( cvs login asks for the password only the first time) • Access to a local repository :local::d:\Documents\...cvsExample • Note: The server can be configured to use SSH for secure communication Create a New Module • If the files for the module are in the local folder wdir cd wdir cvs import –m “source code” rdir creator initial_tag Initial_tag rdir Server Client cvs import “source code” wdir Download an existing module • To download rdir into wdir: cd wdir cvs checkout rdir Server Client rdir cvs checkout rdir wdir Add a File to a Module 1. create a new file in the working copy 2. cvs add <nome_file> 3. cvs commit <nome_file> rdir rdir FILE Server Client cvs add… cvs commit… wdir FILE Changes • Changes are always made to the local copy (working copy) • Possible changes – Change the content of a file – Add a file/folder (cvs add) – Remove a file/folder (cvs remove) • Other changes are obtained combining the above changes • Changes are finalized with cvs commit –m “comment” – Use meaningful comments! – Use a naming convention CVS update • “cvs update” marks files as follows: – CHANGES GENERATED BY THE REPOSITORY – U updated: new file or new revision of existing file downloaded from the repository – CHANGES NOT UPLOADED YET – A Added: the new file has been added to the working copy (cvs add) but not to the repository (cvs commit not executed yet) – R Removed: file removed from working copy (cvs remove) but it is still present in the repository (cvs commit not executed yet) – M Modified: the file has been updated locally but not on the working copy (cvs commit not executed yet) – FILES NOT UNDER VERSION CONTROL – ? The file is in the working copy, but it is not under version control – CONFLICTS – M Merged: cvs has modified the file locally to merge conflictual changes. Commit must be executed to upload the changes to the server. – C Conflict: the file has been modified both locally and on the repository, and cvs has not been able to merge changes Concurrent Development • Concurrent activity might generate conflicts • Update before Commit to reveal conflicts – Conflicts must be resolved by the developer who has to commit changes – This rule might affect the behavior of the developers… • When a change (e.g., to code) can be committed? DEMO • CVS by example… Subversion Subversion • • • • More recent than CVS Simpler than CVS Overcome some limitations of CVS There are anyway pros and cons Folder • Subversion implements most of the concepts using folders as paradigm • Tags – Copy and paste the folder with the project • Branches – Copy and paste the folder with the project – Work on the pasted folder Typical repository in subversion • <root> Users usually checkout the trunk, and not the repository – trunk – branches – tags • Examples – trunk • file1.dat • folder1 • folder2 – branches • lightRelease – file1.dat – folder1 • limitedFeatureRelease – – – – file1.dat file2.dat folder1 folder2 – tags • rel1Light – file1.dat – folder1 Subversion vs CVS Pros SVN • Atomic commit • SVN implementations perform typically better than CVS implementations • SVN efficiently stores binary files Pros CVS • SVN has a unique version number for the whole repository, while CVS assigns version numbers to the individual files • SVN “simulates” tags • in case of “disasters”, the CVS repository is easily readable (text files), while SVN is not Examples from the Pro Git Book GIT VERSION CONTROL From Client-Server to Distributed Version Control Remote Repository Local Repository Local Repository <repository, working directory> Local Repository GIT • Distributed version control • Used by many popular open source projects Bare repository: shared by multiple developers push/pull Non-Bare repository: single developer repository • There is almost nothing you cannot do locally GIT Snapshots Non-GIT GIT Working Directory Local Repository Local Repository commit checkout Change (modify/add/delete) Working Dir Staging Area Staging Area add add Change Working Dir V2 Working Dir V2 File Status Tracked add Untracked Modified stage edit remove Unmodified commit Staged Create a GIT Repository • Go into working directory • Type – git init – git clone git://… working directory .git … Working copy Repository … GIT DEMO 1. Create a local (non-bare) GIT repository in an empty folder 2. Add files 3. Stage files 4. Commit Files 5. Look at the Repository with SmartGitHg 6. Modify files 7. Remove Files 8. Commit changes 9. Look at the Reporitory 10. Keep doing this Distribution Remote Repository Remote Repository Remote Repository git push git fetch Data in Remote but not in Local is simply added rem1 rem2 origin Local Repository Data from multiple remote repositories coexist because branches have the repository name as prefix, e.g., rem2/master git pull If a branch tracks a remote branch. PULL = FETCH + MERGE Conflicts pull Local Repository 1 Remote Repository pull push push pull push Local Repository 2 Merge/resolve conflict Branching Branching • GIT implements lightweight branching • Branch often, even multiple times a day! • Let’s start from the content of a GIT repository Single Commit snapshot Multiple Commits Branching Create Branches HEAD Work With Branches git checkout testing Work With Branches git commit What’s the new configuration? Work With Branches git commit Work With Branches git checkout master What’s in the working Directory now? Work With Branches git commit Branching: a case Branching: a case Need to work on issue 53 Branching: a case Need to work on issue 53 Branching: a case Hotfix urgently needed! How many branches have we created so far? Branching: a case Fast forward merge Branching: a case Drop branch Further develop ISS53 Branching: a case Merge ISS53 Branching: a case Merge ISS53 Remote Branches Remote Branches Remote Branches What does it happen with get pull instead? Merge vs Rebase Merge case Merge vs Rebase Rebase case Git • Efficient, modern, distributed version control system – Advanced branching mechanisms • Many hosting services available online • GitHub (github.com) – Hosting service – Developers community – Web-based interface – Access control – Collaboration features (including wikis, etc.) From Version Control to Continuous Integration • When a new version is ready, a number of quality control activities can be executed – Testing – Analysis –… • Why not executing them regularly? – Or after every commit? Example: Continuous Integration Policy • A time (say 5pm) for delivery of system components is agreed • A new version of a system is built from these components by compiling and linking them • This new version is tested using pre-defined tests – See the second part of the lecture for information about testing and analysis • Faults that are discovered during testing are documented and returned to the system developers CruiseControl Build Loop