Project architecture in Software Configuration Management


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