Introduction

From a developer point of view, software configuration management (SCM) is often associated with a specific SCM tool, being open or proprietary.

Indeed, the used SCM tool is important and may engage a project team or a company for a long time.

But the configuration architecture also is important. Moreover, the SCM architecture for a project does not necessarily correspond to the software architecture. A Software Configuration Item (SCI) is not always a software modules or componants.

Why using configuration management ?

To keep history

The first need for a configuration management system is tracing the files history : date, version, contents.

How often a SCM user wishes to have the same system for its word processing documents !

To share between development team

When many people share the same code base, the SCM tool facilitates synchronization between them.

To manage the product life cycle

A product life does not stop once commercialized. Depending on products, a client may ask for changes many years after. Indeed, a software that no more changes should be considered as dead (see Allan Kelly’s point of view).

So, at any time, we should be able to retrieve and re-generate a whole project :

• Documentation : specifications, test reports, …
• Source code (sometimes only to investigate), including build configurations
• Rebuild all the projects outcomes (documentation, configuration, binaries such as executables, libraries, file systems, …)

• Trace all necessary tools :

• Compilers
• Source code generator
• Build tools and also their own generators (such as Makefile generators)
• …

• Trace all modifications/changes

A project shall a unique entry point !

Deliver a deliverable !

The main action in a SCM system is the delivery !

A product outcome (embedded firmware, web site, client software, …) is

• Made of many contributions (being internal or external), each delivered.

• Itself a delivery

A delivery is always made of :

• A content : the delivery itself made of
  • A single file or a set of files (tree structure), being
  • Binary files or source files or documentation files
• A reference : a milestone or version number
• A reason to deliver : bug correction, new functionalities, …

So, a Software Component Item (SCI) or delivery

• Corresponds to the process
  • External deliverable from a supplier or partner (ingoing)
    (with or without sources)
  • Internal deliverable from internal developments (internal)
  • Outside deliverable to a partner or client (outgoing)
• Shall  be easy to
  • Update (when it is an external delivery)
  • Deliver for internal development (or aggregation/integration)
  • Manage for parallel developments
• Has its own version numbering scheme

Un projet – des fichiers – des composants

Un projet est composé de plusieurs fichiers, parfois groupés en composants.

Chaque fichier a sa propre version. Mais au niveau du projet on ne parlera que d’une seule version du projet

Niveau Méta

Intérêt des composants

Plusieurs projets

Cycle de vie – livraison

Modules ou composants

Les outils