Modélisation du cycle de vie du logiciel

Introduction

La modélisation du cycle de vie d'un logiciel consiste à suivre le code source dans les différentes étapes de sa vie, du développement au test, en passant par le versioning, la réutilisation et la désaffectation. Le présent document décrit la prise en charge par Perforce de la modélisation du cycle de vie et procure un modèle de référence. Mais il décrit avant tout la modélisation du cycle de vie de la façon dont les autres systèmes GCL la prennent en charge, en utilisant le modèle de "promotion".

Le modèle de promotion (différent de Perforce)

La fonction prédominante du modèle de promotion concerne l'utilisation du tronc du code source. Les caractéristiques contributives sont la prise en charge ou non par le modèle de la promotion des fichiers distincts ou des projets complets, et l'utilisation de la branche.

Dans le modèle de promotion, le tronc du code source passe par différentes phases au fil du temps. La phase de chaque révision de chaque fichier est indiquée par quelques attributs dont les définitions sont élaborées à l'avance en vue de refléter le cycle de vie souhaité du code source. En règle générale, les valeurs sont "développement", "AQ", "version" et "désaffection". Les diverses révisions de chaque fichier du tronc s'effectuent généralement à différentes phases : la révision du sommet pourrait se situer dans la phase "développement" tandis qu'une version antérieure de l'année précédente pourrait appartenir à la phase "version".

Le concept de promotion intervient lorsqu'une révision d'un fichier est considérée comme étant prête pour passer à la phase suivante. La révision est alors promue. Par exemple, lorsqu'un ingénieur a terminé d'ajouter des améliorations et qu'elles sont prêtes à être testées, il peut promouvoir la nouvelle révision de la phase "développement" à la phase "AQ." Il arrive qu'une révision soit rétrogradée ; si elle échoue au niveau de l'Assurance Qualité, elle peut alors être rétrogradée à la phase développement en vue d'être améliorée. En raison de cette notion de promotion/rétrogradation, les phases sont généralement appelées "niveaux" de promotion.

Les systèmes GCL qui prennent en charge le modèle de promotion disposent toujours de quelques moyens pour demander la révision la plus récente d'un niveau de promotion donné. L'ingénieur AQ demandera la dernière révision "AQ" de tous les fichiers. Le développeur travaillera sur les révisions du "développement". Une version d’un produit sera créée à partir des révisions indiquées comme "version".

Les systèmes GCL assignent souvent à chaque utilisateur un ou plusieurs "rôles" qui définissent son accès aux révisions à chaque niveau de promotion. Par exemple, seuls les ingénieurs AQ seront en mesure d'extraire des fichiers dont le statut est "AQ", et seul un responsable de la version pourra promouvoir des fichiers "AQ" au niveau "version".

Un autre problème épineux survient lorsqu'une personne a besoin de changer une révision d'un fichier qui n'est pas le sommet. Le sommet se trouvera généralement en phase "développement", mais si l'Assurance Qualité détecte un bogue après qu'un développeur a procédé à de nouvelles améliorations, une révision qui n'est pas le sommet peut devoir être mise à jour. Une solution à ce problème consiste pour le système GCL à créer une branche ad hoc au niveau de la révision qui doit être mise à jour. C'est l'approche de ClearCase. Si le passage du code au niveau AQ est soumis à une activité soutenue, quelques branches peuvent pousser sur le tronc et la version finale peut être un peu "broussailleuse". Une autre approche consiste à archiver la révision mise à jour qui n'est pas le sommet comme étant malgré tout le nouveau sommet. Le système doit ensuite "entrelacer" les révisions liées (toutes celles qui sont au même niveau de promotion) en remontant le tronc de l'historique de révision du fichier. Les différents niveaux de promotion sont essentiellement traités comme des branches distinctes dans le fichier. PVCS^® utilise cette approche.

Hormis ces branches ad hoc, les branches issues du tronc sont largement utilisées pour le développement parallèle. Ces branches qui partent du tronc peuvent appartenir à différents projets, chacun fusionnant régulièrement ses contributions en retour. Les branches elles-mêmes passent par des niveaux de promotion, mais elles sont généralement considérées comme étant au niveau "développement".

Projet et promotion de fichier

Certains systèmes GCL "plus granuleux" regroupent les fichiers en "projets" et leur modèle de promotion prend en charge la promotion de ces projets dans leur ensemble plutôt que les fichiers distincts. L'avantage de ces systèmes est qu'il y a bien moins de détails que l'utilisateur doit éventuellement mémoriser ; l'inconvénient est qu'ils limitent la flexibilité car la granularité de la promotion est déterminée lorsque le projet est créé, et non pas lorsqu'il est promu.

Projet et ramification de fichier

Les systèmes qui prennent en charge les projets limitent également souvent leur ramification à l'ensemble des projets. Ce phénomène est parfois décrit comme la "ramification de la ligne de base", car toute la ligne de base d'un produit est ramifiée en même temps. La ramification de la ligne de base est accompagnée d'une capacité de promotion légèrement supérieure : chaque projet peut avoir ses propres niveaux de promotion. Le tronc peut rester la ligne directrice du développement, avec des niveaux de promotion qui reflètent le cycle de développement. Une branche de ligne de base du ou des projets de développement peut parfois être utilisée pour une version, avec des niveaux de promotion reflétant le cycle de version.

Inconvénients

L'obscurcissement d'informations importantes constitue le principal inconvénient du modèle de promotion. Outre le nom du fichier, le numéro de révision et le niveau de promotion déterminent tous l'objectif courant du fichier. Alors que le nom du fichier est toujours visible, la signification du numéro de révision et le niveau de promotion sont bien moins apparents. La plupart des systèmes GCL utilisent des mécanismes de protection codés de manière irréversible pour empêcher les ingénieurs (autrement honnêtes) de modifier les mauvais fichiers.

De plus, l'historique du suivi peut être compliqué. L'historique du tronc d'un fichier peut être incomplet (avec une ramification ad hoc) ou relativement confus (avec des branches qui s'intercalent comme niveaux de promotion).

Enfin, il est fréquent que l'historique de promotion n'inclue pas le niveau "version", ainsi qu'un historique de fichier normal. Si un fichier est promu puis rétrogradé, il peut s'avérer impossible de reproduire une version réalisée lorsque le fichier était au niveau promu. En règle générale, une seule révision peut être au niveau promotion. Si un fichier a été promu l'an dernier au niveau "version" et qu'une nouvelle révision est prête pour une nouvelle version, soit un attribut de promotion différent doit être créé soit le niveau de promotion de la version précédente sera perdu.

Le modèle Perforce

Dans le modèle Perforce, le tronc du code source a un objectif unique : il s'agit de la ligne directrice du développement. Autrement dit, son niveau de promotion sera toujours considéré comme étant le niveau de "développement".

Perforce met en œuvre la promotion par la ramification. Les capacités à la fois rapides et à faibles frais généraux de Perforce en matière de ramification ainsi que la prise en charge de l'intégration le rendent possible. La première fois que les fichiers sont promus, ils sont ramifiés depuis le tronc dans une branche. Les révisions ultérieures qui ne sont pas promues sont fusionnées depuis le tronc dans la branche. Les différents niveaux de promotion étant en fait des branches distinctes, ils peuvent évoluer distinctement.

Le mécanisme de ramification de Perforce, appelé Inter-File Branching™, crée des branches en copiant (pour ainsi dire) des fichiers et en leur attribuant un nouveau nom. Chaque fichier poursuit alors avec un processus de révision indépendant. Aussi, lorsqu'un fichier du tronc est ramifié, il pourrait s'agir de //depot/main/db/dbhdr.h qui est ramifié dans //depot/bugfix/2.1/db/dbhdr.h. Cet exemple artificiel correspond à ceux qui vont suivre, mais il est important de noter que Perforce peut ramifier n'importe quel fichier dans n'importe quel autre fichier. //depot/a/b peut être ramifié dans //depot/c si vous le souhaitez. Pour notre ramification, nous choisissons d'utiliser les identifiants directement après //depot afin d'indiquer le nom de la branche ; cette branche est ensuite appelée "ligne de code".

Perforce peut ramifier des fichiers distincts, des groupes de fichiers ou l'ensemble du "dépôt". Toutefois, Perforce ne prend pas en charge la ramification ad hoc lorsqu'un fichier peut être extrait d'une branche dans une autre. L'une des raisons tient à ce que cela est beaucoup plus simple à comprendre ; la ramification est toujours un acte explicite. Les performances de Perforce en matière de ramification rendent possible la ramification de grands groupes de fichiers en même temps.

Ainsi, lors de la promotion de fichiers, l'approche recommandée avec Perforce consiste à ramifier tous les fichiers qui doivent être promus.

Le modèle de cycle de vie de référence Perforce

Cette section décrit une méthode d'utilisation particulière du modèle Perforce. Quelles variations sont également proposées.

Il est possible d'imiter le modèle de promotion décrit précédemment avec Perforce. Il suffit pour cela d'utiliser la ramification pour promouvoir des groupes de fichiers de //depot/development dans //depot/qa, puis de //depot/release, etc. Mais cela peut impliquer que la ligne de code de la "version" soit utilisée à plusieurs reprises pour les versions multiples, intégrant à chaque fois les changements à partir de la ligne de code "AQ" (puis de la ligne de code "développement"). Ceci est certainement possible, mais chaque version est une entité distincte qui doit être nommée en tant que telle.

Un critère plus précis impose la ramification d'une ligne de code si son utilisation prévue est incompatible avec sa politique d'utilisation. Par exemple, la politique de la ligne de développement (stipulant qu'elle peut accepter une nouvelle fonctionnalité) est généralement incompatible avec la création de versions stables ; ainsi, les lignes de version doivent être ramifiées depuis les lignes de développement. En outre, la politique des anciennes versions autorise généralement les modifications pour les correctifs d'urgence uniquement. Ce qui n'est pas cohérent avec la politique d'une version plus récente, qui autorise une correction des bogues plus fréquente.

C'est pourquoi nous proposons un modèle qui tire avantage de la ramification performante de Perforce en créant une branche pour chaque ligne de code ayant une politique unique.

Ligne directrice

Dans le modèle Perforce de référence, le tronc est la ligne de développement primaire. Elle est appelée ligne "directrice", ce qui signifie que les fichiers se trouvent sous //depot/main ; elle représente les bijoux de famille de l'entreprise. Tandis qu'un code plus récent peut être développé dans des branches de développement spéciales, la ligne directrice est la destination ultime pour tous les développements logiciels. Les correctifs et les changements de portage effectués dans les lignes de la version doivent l'être en retour dans la ligne directrice. Il est possible que certaines modifications soient apportées directement dans la ligne directrice si cela est souhaitable. Une bonne politique pour la ligne directrice est qu'elle devrait toujours être compilable. Une meilleure politique est qu'elle devrait toujours réussir ses tests.

Lignes de maintenance

Au cous du développement du produit, des versions doivent être réalisées. La ligne directrice est ramifiée au point de divergence entre la politique de la ligne directrice et les besoins de la version, à savoir, lorsqu'une nouvelle fonctionnalité n'est plus souhaitée dans la version. La nouvelle ligne est alors appelée ligne de maintenance et un nom qui reflète le nom de la version lui est attribué. Par exemple, pour la version 3.5 d'un produit, la ligne pourrait s'appeler //depot/bugfix/3.5.

La création d'une ligne de maintenance est quelque peu semblable à la promotion des fichiers du niveau "développement" au niveau "AQ". Mais la ligne est nommée d'après son utilisation prévue plutôt que d'après son utilisateur actuel, et son nom inclut le numéro de version. En incluant le numéro de version, nous indiquons clairement que cette ligne ne peut être réutilisée pour d'autres versions.

Une fois la ligne de maintenance créée, elle est isolée des modifications apportées à la ligne directrice. Le déplacement de ces modifications dans un sens ou un autre exige une action explicite de la part de l'utilisateur. Perforce facilite cette action, mais elle reste soumise à une requête explicite. La propagation des modifications de la ligne directrice à la ligne de maintenance est semblable à la promotion de nouvelles révisions au niveau"AQ". Contrairement au modèle de promotion, qui permet uniquement de remonter les modifications sur le schéma de promotion, le modèle Perforce autorise le développement indépendant (personnalisation, correction de bogues, etc.) dans la ligne de maintenance, et par la suite la fusion en retour dans la ligne directrice.

Lignes de version

Au cours du test, la ligne de maintenance sera détectée comme étant prête pour passer au niveau version. La ligne de maintenance est ramifiée au point de divergence entre la politique de la ligne de maintenance et les besoins d'une version, à savoir, lorsque seuls des correctifs d'urgence sont autorisés. La nouvelle ligne est alors appelée ligne de version et un nom qui reflète le nom de la version lui est attribué. Par exemple, pour la première version de notre ligne 3.5, nous pourrions ramifier la branche //depot/bugfix/3.5 dans //depot/release/3.5/01.

La création d'une ligne de version est semblable à la promotion des fichiers du niveau "AQ" au niveau "version". La ligne de version, avec un peu de chance, ne changera jamais après sa ramification. Toutefois, elle peut servir de ligne pour un ou plusieurs correctifs d'urgence en cas de besoin.

La ligne de maintenance à partir de laquelle la ligne de version est ramifiée peut évoluer au fil du temps et accepter des correctifs ou des améliorations sélectionnées dans la ligne directrice. Si tel est le cas, elle créera d'autres versions (/02, /03, etc.). Une telle activité peut se poursuivre jusqu'à (voire après) ce que la ligne directrice crée une autre ligne de maintenance, telle que //depot/bugfix/3.6.

Désaffectation

Les lignes de maintenance et les lignes de version ne perdent jamais leur identité. La désaffectation de ces lignes intervient lorsque l'activité cesse. Une ligne peut redevenir active simplement en l'utilisant de nouveau.

Commentaires

Une caractéristique importante du modèle Perforce est que la pertinence d'un fichier est encodée dans son nom : //depot/release/3.5/01/db/dbhdr.h est un fichier qui fait partie d'une version, et qui n'est clairement pas l'emplacement pour des améliorations diverses. De même, //depot/main/db/dbhdr.h n'est clairement pas l'emplacement où des produits pouvant être expédiés sont construits. De plus, l'ensemble de la version 3.5/01 se trouve sous //depot/release/3.5/01 et nulle par ailleurs dans le "depot". Cette approche simple comme bonjour est la marque de fabrique du modèle de ramification Perforce.

Une caractéristique non moins importante du modèle Perforce est qu'une ligne de code peut donner naissance à plusieurs lignes "au niveau de promotion suivant". Autrement dit, la ligne directrice peut créer plusieurs lignes de maintenance qui peuvent être actives en même temps. Le modèle de promotion normal ne le permet pas car une seule révision peut se trouver à un niveau de promotion donné. Malheureusement, plusieurs versions actives de plusieurs lignes de maintenance sont une réalité avec les grands produits logiciels.

Variations

Le développement ne doit pas directement se produire sur la ligne directrice. Les développeurs individuels ou les groupes peuvent ramifier la ligne directrice en lignes de projet nommées //depot/dev/projet, où "projet" est le nom de l'utilisateur ou du groupe. Dans ce cas, il n'est probablement pas nécessaire de ramifier l'ensemble de la ligne directrice, mais seulement les zones susceptibles d'être modifiées. Par exemple, le groupe de développement de la base de données peut ramifier les fichiers sous //depot/main/db dans //depot/dev/fast-db/db pour un projet d'amélioration des performances.

Tous les projets n'ont pas besoin à la fois de lignes de maintenance et de lignes de version. Une version peut parfois être réalisée directement à partir des lignes de maintenance. Cela convient parfaitement aux petits produits ou aux produits dont le cycle de vie est court. La version des produits vraiment petits peut en fait être issue de la ligne directrice.

Il n'est pas nécessaire de créer la branche au point de divergence des politiques. L'utilisation d'une étiquette pour désigner le point de ramification prévu permet de reporter indéfiniment la ramification réelle. Si, par exemple, la ligne directrice est estimée suffisamment stable pour passer au niveau "test", les révisions actuelles peuvent alors être indiquées par une étiquette. Si le test révèle que la ligne directrice a encore du chemin à parcourir, celle-ci peut être réparée et l'étiquette déplacée vers le haut. En revanche, si le test révèle que la ligne directrice (au niveau de l'étiquette) est prête pour être déplacée sur une ligne de maintenance, Perforce peut ramifier la ligne directrice au niveau de l'étiquette dans la ligne de maintenance.

Conclusion

La prise en charge du cycle de vie de Perforce et son modèle de cycle de vie de référence reposent sur le mécanisme hautes performances Inter-File Branching™. En ramifiant des lignes de code entières et en utilisant l'espace de noms pour indiquer les branches, Perforce apporte une prise en charge claire et compréhensible du logiciel.