Software Configuration Management

Use "a" key to toggle between single page and slideshow modes. Use the space bar or right arrow for next slide,
left arrow to back up.

What comprises a software product?

A set of files, containing:

All of these evolve through multiple versions.

Definition according to Wiki

Configuration management is the management of features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures and test documentation of an system, throughout the development and operational life of a system.

Source Code Management or Software Configuration Management (both "SCM") is part of this.

Definition according to Dennis et al.

Configuration and change management is the tracking of the state of the artifacts (hardware, software, firmware, documentation, tests, test fixtures, and test documentation) throughout the development and operational lifetime of a system.

Software Configuration Management

What is the problem?

*

What is the problem?

Scenario

Scenario

Scenario

Scenario

What artifacts make up a system configuration?

What is a software configuration?

  • A collection of versions of files and directories
  • That logically belong together
    • because they are being tested together (a development configuration)
    • or because they are to be delivered together (a release)
*

SCM Goals

Complicating Factors

SCM Tools

A revision control (also called "version control") tool allows you to track revisions to both files and collections of file versions (configurations), obtain copies of past versions at any point, and roll back to older versions if you desire.

There are many different revision control tools, of both commercial and open source varieties. Integrated development environments typically will include a revision control system. You can also use revision control tools in a stand-alone fashion.

SCM Tool Capabilities

Track files, or entire configurations

Two SCM Models

Two Update Models

Three Ways of Handling Concurrent Updates

What is Managed

Some Core SCM Concepts

  • File vs. configuration
  • Version/revision numbers
  • Timestamps
  • Releases
  • Repository
  • Working copy, or "sandbox"
  • Baseline/Trunk/Mainline
  • Branches/Forks
  • Change list, or patch

More Terms & Concepts

Centralized SCM (svn)

* Operations require a server
  • single point of failure
  • bottleneck
Simpler to use

Decentralized SCM (git)

* Anyone can be a server
More versatile
More ways to get confused & shoot foot

Examples of SCM Tools

Git Repository

Contains
  • files
  • commits
  • ancestry relationships
*

The nodes in the DAG are configurations, not files.

How Decentralized (git) SCM Works

* Anyone can be a server

How Decentralized (git) SCM Works

* Start with a global repository

How Decentralized (git) SCM Works

* Make a local copy by cloning it

How Decentralized (git) SCM Works

* Cheap local clones can be made via links

How Decentralized (git) SCM Works

* Changes can be pushed back upstream

How Decentralized (git) SCM Works

* You can publish to a Web server

How Decentralized (git) SCM Works

* Or you can share with trusted peers

Workflows

An Agile Workflow for Git (or Svn)

* All developers are equal.
All pushed changes to same repository.
Repository is always up to date with the current "wave front".

See Pro Git at http://progit.org.

UML Sequence Diagram for this Workflow

*  

A Git Branching Workflow Model

* Distinguishes feature, development, release, hotfix, and master branches

See nvie.com.

A Managed Repository Model

* Only one person can push changes to the blessed repository.
Means less chance of accidents, but we now have a bottlneck.

See Pro Git at http://progit.org.

Linux-like Hierarchical Model

*  

See codebeamer.com.

Android Git Workflow Model

* Two kinds of review, verification by multiple testers before admission to repository.

See source.android.com.

"Story branch" pattern with git

  1. Choose a feature/task/story to work on, and mark it as being worked on (presumes a workflow tool is being used)
  2. Git a fresh copy of the baseline code tree
    git checkout master
    git pull
  3. Make a branch to work in
    git checkout -b storybranch
  4. Write a test for the feature/story
  5. Make changes to the code, commiting often
    git commit -am "summary of what changes I made just now"
  6. When the test passes, do another commit, and cycle back to step 4, until the feature/story is believed to be complete
  7. Merge with master
    1. Review changes
      git diff master
    2. Merge changes
      git checkout master
      git pull
      git checkout storybranch
      git rebase master
    3. Do this frequently, to keep in sync. with other changes.

  8. Correct any conflicts, and repeat until convergence
  9. Push new version back to the trunk
    git checkout master
    git merge storybranch
    git push
    git checkout storybranch
    This presumes there are no merge conflicts.

Combined from Agile git and the story branch pattern and Hack && Ship

Notes:

CM Standards

References