Introduction

Bien souvent, quand on parle de gestion de configuration logicielle, on entend parler de tel outil ou tel autre, libre ou propriétaire.

Certes, choisir son outil de gestion de configuration est fondamental et peut engager un projet ou une entreprise durablement.

Mais l’architecture de configuration aussi est importante. Surtout, l’architecture de configuration d’un projet n’est pas nécessairement calquée sur l’architecture logicielle en modules ou composants.

Pourquoi utiliser une gestion de configuration ?

Pour conserver l’historique

L’utilisation première d’un système de gestion de configuration est de tracer l’historique des fichiers : date, version, contenus.

Combien de fois un habitué souhaiterait le même système pour son traitement de texte !

Pour partager au sein de l’équipe de développement

Quand plusieurs personnes partagent la même base de code, l’outil de gestion de configuration facilite la synchronisation dans l’équipe.

Pour gérer le cycle de vie d’un produit

La vie d’un produit ne s’arrête pas à la date de commercialisation. Selon les produits, un client peut demander des changements plusieurs années après. En fait, un logiciel qui ne change plus n’est plus ‘vivant’ (voir les propos d’Allan Kelly).

A tout moment, on doit pouvoir retrouver et re-générer un projet complètement :

• Documentation : spécifications, rapports de tests, …
• Code source (à minima pour investiguer), y compris les configurations de génération
• Reconstruire tous les résultats (documentations, configurations, binaires = exécutables, librairies, systèmes de fichiers, …)

• Tracer les outils nécessaires à cette reconstruction :

• Compilateurs
• Générateur de code source code
• Outils de génération et leurs propres générateurs (par exemple, des générateurs  de Makefile)

• Tracer toutes les modifications/changements

Un projet doit donc avoir un point d’entrée unique !

Livrer un déliverable !

Le principal usage d’un système de gestion de configuration logicielle est la livraison !

Un produit (firmware embarqué, site web, logiciel client, …) est

• fait de plusieurs contributions (qu’elles soient internes ou externes), elles-même délivrées.

• en soi une livraison

Une livraison est toujours faite de :

• Un contenu : la livraison elle-même, faite de
  • Un seul fichier ou un ensemble de fichiers (sous forme d’arborescence), étant
  • des fichiers binaires et/ou des fichiers source et/ou des fichiers de documentation
• Une référence : une borne ou numéro de version
• Une raison pour livrer : correction de bugs, nouvelles fonctionalités, …

Donc, un SCI (Software Component Item) ou une livraison

• Correspond au process
  • Livrable entrant d’un fournisseur ou partenaire (ingoing)
    (avec or sans sources)
  • Livrable interne d’autres équipes de developpements (internal)
  • Livrable sortant vers un partenaire ou un client (outgoing)
• Doit être facile à
  • Mettre à jour (quand il vient de l’extérieur)
  • Livrer pour des developpements internes (or agrégation/intégration)
  • Gérer pour des développements parallèles
• Possède son propre schéma de version

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