Download Version_Control-Mari.. - HPC

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