configuration & change management · keeping track of changes analyzing impact & approving...
TRANSCRIPT
Configuration & change
management
Karel Kravik
Configuration management is ...
� ... the process of identifying and defining the
Configuration Items in a system, recording
and reporting the status of Configuration Items
and Requests For Change, and verifying the
completeness and correctness of Configuration
Items.Items.
� Abstract term, most people get it wrong
� When software is in use, “configuration” refers to
set of parameters and their values
� When software is in development, “configuration”
refers to some known state of source code
What is Configuration Item?
� Configuration Item can be:
� Document
� Specification
� Requirement
� Database table
Website content� Website content
� But in everyday life, configuration items are
source code files and instead of CM we talk
about “version control”
Diff & merge
� Diff – refers to differences between two files
� Merge – the operation of taking differences
between two files and applying to the third
� Configuration management is vastly easier task
if we can define diff & merge algorithms for
configuration itemsconfiguration items
� Consider text files vs Word documents
� Why are wikis popular?
Diff & merge
A1+A2
� Low level tools
� diff
� diff3
A
A1 A2
Basic versioning
VCS tools
� CVS (concurrent versions system) – old, but
still widely used
� Subversion – “compelling replacement for CVS”,
newer, popular, but generally not what people
would like it to be
There are plenty of commercial tools: � There are plenty of commercial tools:
� Perforce
� IBM ClearCase
� BitKeeper (distributed VCS)
� MS Team Foundation
� We take CVS as an example
Version control (centralized)
Working directory 1
Working directory 1
Repository
Main concepts
� Repository
� Working directory
� Revision/revision history
� Change/changeset
� VCS client/server� VCS client/server
Repository - files
A B C D
A C
Repository files & history
A CA B C
A B C DA B C D
A B C D
Basic version control operations
� Checkout – creates new working directory
� Commit – pushes local changes to central repo
� Update – pulls changes committed by others
from repo
� Merge – parallel changes are incorporated� Merge – parallel changes are incorporated
� Conflict - same file is changed within certain
context
� Add – add file to source tree
Usual work process
� Checkout
� Edit code
� Compile, deploy, test
� Commit
� Resolve conflicts if needed
� Update
� Pull other people’s changes to my working directory
� Resolve conflicts if needed
� Edit code
� Commit
� ....
Conflicting changes
diff3 can integrate changes from two modified versions into a common preceding version. This enables users to merge the sets of changes represented by the two newer files. This can be enabled using a command like this: diff3 mine older yours.
diff3 can integrate changes from two modified versions into a common preceding version. This enables users to merge the sets of changes represented by the two newer files. This can be finished using a command like this: diff3 mine older yours.
diff3 can incorporate changes from two modified versions into a common preceding version. This enables users to merge the sets of changes represented by the two newer files. This can be accomplished using a command like this: diff3 mine older yours.
Conflict markers
diff3 can incorporate changes from two modified
versions into a common preceding version. This
enables users to merge the sets of changes
represented by the two newer files.
>>>>>>>>>>>>>>>>
This can be accomplished using a command like This can be accomplished using a command like
this: diff3 mine older yours.
================
This can be finished using a command like this:
diff3 mine older yours.
<<<<<<<<<<<<<<<<
Tagging & branching
Advanced concepts - tag
� Tag marks certain revision(s) of file(s)
A CA CA B C
A B C DA B C D
A B C D
Uses for tag
� Denoting some known state:
� ReleaseX – so you can reproduce released version
� BeforeRefactorX – if you need to undo, you know
the “good” state
� BranchpointX – where some branch started
� You can tag:� You can tag:
� Whole repository
� Any subdirectory
� One file
� To keep it manageable, tag whole repository
AA B
Advanced concepts - branch
A CAA B
A CA B C
A B C DA B C D
A B C D
AA B C D
A’ B’ C’ D’
Uses for branch
� Support branch – you need to fix bugs in
released version and develop new functionality
� Experimental branch - test some earth-shaking
change
� Staging branch – code propagates from less
stable branch to more stable branchstable branch to more stable branch
Limitations for branching
� There is one substantial limitation – the
complexity of merge operation
� If there are conflicts, merge must be done manually
� Resolving conflicts is error-prone
� You have to track what you merge, where you
merge, when you mergemerge, when you merge
� Conclusions:
� You must have a good reason to create a branch
� Don’t avoid them at any cost
Branching models & code propagation
� Different models:
� No branching, code freeze
� Branch-off on release
� Continuous forward integration
� For more see:
� "Streamed Lines: Branching Patterns for Parallel
Software Development" by Brad Appleton, Stephen
Berczuk, Ralph Cabrera, and Robert Orenstein
Code freeze model
Release
Stabilizing SupportDevelopment Development
Branch-off on release model
Stabilizing Support
Resync
Release
Development Development Development
Stabilizing
Continuous integration model
Development
Stabilizing
Support
Continuous resync
Release
Development
Stabilizing
Stabilizing
Development
Development
More on tools: CVS vs SVN
� SVN advantages:� Atomic commits (cross-repository revision nr)
� Versioned directories, renames & meta-data
� Cheap tagging & branching - O(1) complexity
� It’s in active development
� SVN disadvantages :� SVN disadvantages :� Somewhat slower update & commit
� Everything is a directory - you’re exposed to repo structure
� You can commit against a tag, because, surprise, it’s a directory
� I still recommend it☺
Linus Torvalds on CVS & SVN
� For the first 10 years of kernel maintenance, we literally used
tarballs and patches, which is a much superior source control
management system than CVS is, but I did end up using CVS
for 7 years at a commercial company and I hate it with a
passion.
� Because my hatred of CVS has meant that I see Subversion as
being the most pointless project ever started. The slogan of being the most pointless project ever started. The slogan of
Subversion for a while was ‘CVS done right’, or something like
that, and if you start with that kind of slogan, there's nowhere
you can go. There is no way to do CVS right.
� http://www.youtube.com/watch?v=4XpnKHJAok8
Distributed version control
� Every working directory is self-contained
repository, meaning:
� You don’t need network for work
� You can create your own structure
� Changes can propagate between any two
repositoriesrepositories
� You don’t need branches, you just clone whole repo
� It’s powerful and makes possible things
centralized VCS’s never will, but...
� ... you have to know what you’re doing☺
� Successfully used in big open source projects
1
1.1 1.2
Code propagation in distributed VCS
1.1.1 1.1.2
1.1.2.1
1.2.1
Distributed VCS tools
� Freeware:
� Git – used for Linux kernel development
� Mercurial
� Darcs
� Monotone
Commercial:� Commercial:
� Bitkeeper
Modules
Modularizing code base
� When code base grows:
� There is huge amount of code and different
people/teams are responsible for different parts
� VCS operations slow down
� Solution:
Code base is splitted to modules that interact � Code base is splitted to modules that interact
through defined interface
� One team is responsible for one module, the other
for the second module
Problem & solutions
� You need to start keep track which versions of
the modules that are known to work together
� Possible tools to help:
� Maven, Ivy
� But they are not complete solutions:
� No history
� No staging
� Solutions:
� Lots of manual work
� Share source, not binaries
Variability
Variability levels
� Code level (branches)
� Build time
� Deployment (configuration)
� Runtime
Code level variations
� When to use:
� When you need to support older versions
� Different hardware, operating systems, ...
� Different flavors (basic, advanced, enterprise)
� You should keep in mind:
� Transparency is low
� The branches should still have something in
common (ie you merge some bugfixes to more than
one branch), otherwise they’re already separate
projects
Build time variations
� When to use:
� Different languages (if you don’t have to support
runtime language change)
� Different application servers, platforms, ...
� Problems:
Transparency is better, “branches” are code level � Transparency is better, “branches” are code level
and usually side by side
� Clutter in code (maybe somebody remembers the
#IFDEF’s in C code)
Deployment & runtime variations
� Everything else?
� Data sources
� Languages
� External interfaces
� Why do things on lower level?
� Security reasons
� Psychological reasons
Change management
Change management definition
� Identifying & isolating changes
� Keeping track of changes
� Analyzing impact & approving changes
� Applying & propagating changes
� Change management has the same limitation � Change management has the same limitation
like ordinary version control – diff&merge
� Usually meant by CM:
� Changes in requirements, analysis, design
� Changes in configuration, hardware
� Must be dealt using organizational procedures
Code change management
� Changelogic example:
� Every change is done in separate branch
� Branches have identifiable base versions and merge
point
� Every change is reviewed and analyzed based on
changed files listchanged files list
� Every change implements identified task/bug
Environments
� Development environment
� Developers machines
� Shared development environments
� Test environment
� Must be separate from development
� Should be as close to possible to production
� Sync production to test regularly
� Test production updates
� Production environment
� 1 for custom applications
� N for packaged software products
Changes to environments
� What is environment? Something that you can’t
keep under version control:
� Database (structure&data)
� Content
� Environment specific configuration (connections,
libraries)libraries)
Database change management example
� A list of “features” is stored in every used
database instance
� When database is changed, incremental scripts
are added to code and registered as new
features
For example “Alter table USER add column � For example “Alter table USER add column
LASTLOGIN date”
� When new code is deployed, it compares the list
of features it contains and the ones contained
in database and updates if needed
Thank you!