Versionner vos composants JIRA


Publié par
Paul ROCHE

9 janvier 2012

Au rang des nouvelles fonctionnalités que nos clients disent souvent attendre de JIRA, celle de pouvoir attribuer des versions aux composants des projets revient très régulièrement.

Tous les champs de type version dans JIRA (natifs ou customs), ne se rapportent en effet qu’aux seuls projets. Par exemple, le sous-niveau que constituent les composants dans un projet ne bénéficie d’aucune forme de versionnage, alors qu’ils sont souvent amenés à traduire un sous-ensemble technique du système auquel se rapporte le projet. Difficile donc d’envisager de faire de la gestion de configuration très poussée avec le modèle d’objets mis à disposition nativement par JIRA.

Le plugin SQLFeed vous offre la possibilité d’introduire un versionnage de tous les objets que vous voudrez, et pas seulement au niveau juste en-dessous du projet (équivalent des composants), mais sur autant de niveaux enfants que vous le désirerez.

La mise en oeuvre de cette solution s’appuie sur :

  • Un référentiel de base de donnée. L’enjeu est d’arriver à y retranscrire la configuration de votre système par le jeu des contraintes entre les tables. Nous proposons en illustration un mini-schéma qui traduit un système simple sur deux niveaux: composants et sous-composants avec leurs versions respectives.
  • Des champs personnalisés de type SQL. Ces champs, introduits par le plugin, prennent l’apparence de select-lists classiques mais dont le contenu serait dynamiquement mis à jour  par des requêtes vers le référentiel de base de données. Une partie du paramétrage consistera à établir une hiérarchie entre tous ces champs qui s’inspirera de celle déjà faite entre les tables de la base de données.


exemple des versions des composants sqlfeed

On peut donc imaginer une articulation entre trois champs SQLFeed composant/version/sous-composant et qui offrirait à l’utilisateur successivement de :

  1. Saisir un composant
  2. Saisir une de ses versions (le contenu de la liste est impacté par le choix du composant)
  3. Saisir un de ses sous composants (le contenu de la liste est impacté par le choix de la version du composant)
    La version du sous-composant sera exactement celle qui figure dans la version du composant choisie.

La principale contrainte du dispositif résidera dans la maintenabilité de ce référentiel en dehors de JIRA, au gré des mises à jours de tous les composants du système. Si jusqu’à présent, nous n’avons mentionné SQLFeed que pour des requêtes en lecture, on pourrait très bien envisager de créer, au sein d’un projet dédié, de nouveaux champs SQL qui seraient adossés à des requêtes de type insert et update  pour proposer la mise à jour du référentiel depuis l’interface JIRA.

L’introduction du multi-select pour les champs SQLFeed sera une plus-value considérable pour cet use case: l’utilisateur aura ainsi la possibilité de saisir plusieurs composants et/ou versions pour qualifier sa demande. Cette nouvelle fonctionnalité est plannifiée au sein de notre prochaine release (sortie prévue fin Q1 2012)

Nous vous avons présenté ici un usage parmi tant d’autres qui pourraient être faits de SQLfeed. Vous pourriez plus généralement l’utiliser pour requêter sur n’importe quelle base de données (y compris celle de JIRA), et vous constaterez que les champs de type SQL apporteront le dynamisme qui fait souvent défaut à vos écrans.