Développement IT – Méthodes et Outils

Release management BIAT

Gestion des mises en production

1
Développement IT – Méthodes et Outils

Sommaire :
I. Introduction : ................................................................................................................................... 4
II. Concept Objets et Versions ou OV : ................................................................................................ 5
III. Cadre d’activités et définitions. ................................................................................................... 5
a. Gestion de livraisons .................................................................................................................... 5
b. Planification des changements : releases et mini-releases ......................................................... 6
c. Gestion des incidents .................................................................................................................. 6
d. Cohérence des environnements logiciels. .................................................................................... 6
e. Intégration du mode AGILE ......................................................................................................... 7
IV. Modélisation de la solution release management ...................................................................... 7
a. Environnement de production : .................................................................................................. 8
b. Référentiel de versions : .............................................................................................................. 8
c. Transition de tâches opérationnelles sur les circuits de livraisons : ......................................... 12
d. Rôles et activités par circuit de livraison : ................................................................................. 12
i) Circuit HOTFIX :.......................................................................................................................... 12
ii) Circuit Release (Idem pour Digital) : .......................................................................................... 13
iii) Circuit Projet : ............................................................................................................................ 13
e. Schéma global de fonctionnement ........................................................................................... 14
f. Schéma global de gestion des incidents (HOTFIX) .................................................................... 14
V. OVTOOLS : Plateforme de pilotage de la solution release management...................................... 16
a) Accès aux environnements et circuits de livraisons .................................................................. 18
Parmi les écrans OVTOOLS, nous retrouvons l’écran intitulé « Accès aux environnements et circuits
de livraisons », qui offre un raccourci d’accès aux différents environnement et circuit de livraisons.
........................................................................................................................................................... 18
b) Pilotage des taches opérationnelles par circuit de livraison : ................................................... 18
c) Pilotage et Workflow. ................................................................................................................ 18
d) Processus de mise en production :............................................................................................ 19
e) Remontée d’une release au circuit d’intégration à la production : .......................................... 27
f) Contrôle et investigation sur les changements : ....................................................................... 28
g) Reporting sur les changements planifiés : ................................................................................ 29
h) Base de connaissances : ............................................................................................................ 30
i) Niveau d’automatisation des taches opérationnelles : Projet T24:........................................ 31
VI. Conclusion : ............................................................................................................................... 32

2
Développement IT – Méthodes et Outils

Table des illustrations :

Figure 1. Circuit Hotfix ........................................................................................................................... 12
Figure 2. Circuit Release ........................................................................................................................ 13
Figure 3. Circuit Projet ........................................................................................................................... 13
Figure 4. Schéma global de fonctionnement ........................................................................................ 14
Figure 5.Schéma global de PRISE EN CHARGE D’une demande CORRECTIVE ....................................... 15
Figure 6 Schéma global de TRAITEMENT D’UNE DEMANDE D’UN HOTFIX ........................................... 16
Figure 7. Architecture de la plateforme ovtools ................................................................................... 17
Figure 8. OVTOOLS : tableau de bord des environnements / circuits de livraisons .............................. 18
Figure 9. OVTOOLS : vue consolidée des activités opérationnelles ...................................................... 18
Figure 10. Exemple de ticket TRAC ........................................................................................................ 19
Figure 11.OVTOOLS : tableau de bord des demandes de livraisons par acteur et par circuit de livraison
............................................................................................................................................................... 20
Figure 12. OVTOOLS : décrire le livrable pour une intégration automatique ....................................... 20
Figure 13.OVTOOLS : Action d’intégration terminée avec erreur, signalée sur le ticket TRAC............. 21
Figure 14. OVTOOLS : notification automatique, problème de déploiement ....................................... 21
Figure 15. OVTOOLS : Notification automatique, informant l’acteur MOA que sa demande est prête
pour test ................................................................................................................................................ 22
Figure 16. OVTOOLS : Notification automatique de planification de mise en PROD. ........................... 22
Figure 17. OVTOOLS : Reporting avancement de la qualification de release ....................................... 23
Figure 18. OVTOOLS : Tableau de bord commandant la mise en PROD des livraisons qualifiées. ....... 24
Figure 19. OVTOOLS : Message de notification automatique de communication des changements
appliques sur la production. .................................................................................................................. 25
Figure 20. OVTOOLS : Tableau de bord pour lister les CHANGEMENTS APPLIQUER SUR LA PROD DANS
UN INTERVALLE DE TEMPS. ................................................................................................................... 26
Figure 21. OVTOOLS : tableau de bord, listes des tickets appliqués sur PROD à adapter sur le reste des
environnements .................................................................................................................................... 27
Figure 22. OVTOOLS : Résultat d'étude d'intersection.......................................................................... 28
Figure 23. Extrait d'une page wiki ......................................................................................................... 30

3
Développement IT – Méthodes et Outils

I. Introduction :

Dans le cadre de la refonte du système d’information de la BIAT en 2008-2009, qui a abouti à

la mise en place du nouveau système T24, vers la fin de l’année 2011 (Editeur TEMENOS), une
mission IT a été engagée dès le démarrage du projet, pour modéliser et industrialiser l’activité
de gestion des mises en production ou release management. L’objectif, étant de réglementer
et de dynamiser les échanges de livraisons durant tout le cycle de réalisation du projet : A
partir de la demande, le développement, l’assemblage, les tests jusqu’au déploiement final.
Face à des contraintes d’architecture rencontrées dans la version v09 du système T24 en TAFC,
il était difficile de concevoir un modèle CI/CD basé essentiellement sur les outils standards.
En effet, Le système T24, est un Framework qui offre un cadre de développement basé sur un
ancien langage de programmation JBASE, du paramétrage et des outils prêts à l’emploie avec
des formats non structurés (VERSION, REQUETTE, SERVICE, etc.).
Ajouté à ça, le système T24, rassemble les objets applicatifs avec les données clients (fiche
client, compte client, toutes opérations financières clients, etc.) qui sont tous enregistrés sous
forme de RECORD BLOB, dans une même base de données ORACLE. Ainsi, Il devient
pratiquement impossible de mettre une population de développeurs dans un mode
collaboratif, travaillant en natif avec un dépôt de versions que ce soit GIT ou SVN.
Ces contraintes, nous ont ramené à développer notre propre solution release management et
notre CI/CD que nous avons appelé OVTOOLS. Une solution qui réunit une couche de
développements locale, couplée avec un ensemble d’outils OPEN SOURCE (principalement,
l’outil de ticketing TRAC et l’outil de versioning SVN).
Un module important de contrôle d’intégrité des objets paramétrages a été développé, pour
assurer une sécurité sur les données clients contre toute modification non autorisée par les
équipes de développement.
La solution release management, s’est progressivement généralisée pour couvrir et sécuriser
de nouveaux projets critiques en production, autres que T24, tels que MXP (système
monétique), HRACCES (système RH de la banque), etc.
Enfin, pour les projets ou plus précisément les composantes applicatives, qui présentent des
langages standards (classes JAVA, Scripts, APIs, Threads, Triggers, etc.), un nouveau Stream
CI/CD moins spécifique, utilisant des outils originaux du monde de DEVOPS tels que (JENKINS,
Sonarqube, nexus, etc.) a été rajouté à la plateforme OVTOOLS dans un but d’optimisation de
la phase d’intégration continue.

4
Développement IT – Méthodes et Outils

II. Concept Objets et Versions ou OV :

La solution OVTOOLS, a été conçue, en suivant, un concept OV recommandé par l’intégrateur

TEMENOS. Il représente, un ensemble de bonnes pratiques issues du Framework ITIL, dont le
but principal est de garantir une meilleure réactivité et traçabilité des échanges entre les
acteurs projets ainsi que d’assurer la cohérence et la sécurisation du code applicatif, à travers
les différentes phases de planification, de développements, de préparation et de déploiement.

Le concept OV, repose sur l’identification des taches et les rôles pour définir les processus de
livraisons et d’industrialiser les workflows capables d’embarquer ces processus dans un mode
continu pour une meilleure réactivité. Il permet d’offrir un ensemble de services permettant
d’alerter et d’accompagner chaque acteur projet, pour prendre en charge les tâches qui lui
sont affectées pour les traiter dans les meilleurs délais.
Les principales recommandations sont :

• Valorisez la collaboration et la transparence

• Séparer les rôles pour un meilleur suivi des services.
• Favoriser la communication interservices (workflow et notification).
• Favoriser la sécurité du code et des environnements softwares (cohérence des
versions et intégrité).
• Favoriser la documentation et la visibilité (piste d’audit, base de connaissance).
• Capitaliser les données de l'entreprise (centralisation du code et de l’historique)
• Favoriser l’automatisation des processus (meilleure réactivité et efficacité)

III. Cadre d’activités et définitions.

a. Gestion de livraisons
Nous avons défini des circuits de livraisons ou Stream, soit des véritables pipelines de
transition de taches bien programmées. Sur ces circuits, les demandes métiers seront prises
en charge par les développeurs au fil de l’eau. L’objectif, étant de produire des petites
livraisons mais plus fréquentes et de les communiquer aussitôt pour des tests métiers. Les
anomalies constatées, seront retournées automatiquement aux développeurs pour produire
des nouvelles livraisons. Ce mouvement itératif, se poursuit jusqu’à la validation finale besoin
métier.

Parmi ces circuits, nous distinguons le circuit projets qui constitue l’input principale, pour le
démarrage du développement de tout projet à embarquer dans une release. Sur ce circuit, les
projets passent par une phase de tests de qualification avant d’être remontés sur un autre
circuit de certifications pour des besoins de tests de non régressions.

Le démarrage de la phase de certification, exige que les changements de spécifications soient

entièrement arrêtés pour éviter toute perturbation des versions du périmètre applicatif d’une
release. Ce qui réduira les risques de dérapage sur les délais de mise en production.

5
Développement IT – Méthodes et Outils

b. Planification des changements : releases et mini-releases

Les projets de la banque, sont généralement des projets de gestion, où il est souvent difficile
de les découper en modules fonctionnels capables de produire un minimum valeur métier
(MVP), à l’image des projets digitaux. A cet effet, et dans un souci de mettre tout le monde en
activité continue et permettre à chacun de contribuer aussitôt dans la réalisation de projet et
d’y apporter les modifications nécessaires, nous avons adopté un mode de livraisons itératif
au fil de l’eau pour tout demande de changement applicatif.

L’objectif étant, de livrer régulièrement avec un contrôle de qualité dès le départ, tant
technique que fonctionnel. Ainsi, nous avons défini une feuille de route des releases, qui
permet de planifier tous les deux mois une release ou une mini-release. Durant l’année, nous
pouvons planifier trois grandes releases et six mini-releases tel que présenté dans la Template
ci-dessous. Une grande release peut durer environ trois mois où les trois dernières semaines
seront réservées pour la phase de certification ou tests de non régression. Alors qu’une mini-
release ne doit pas dépasser un mois et demi où les deux dernières semaines seront
réservées pour la phase de certification.

Planification des changements : releases et mini-releases

c. Gestion des incidents

La gestion des incidents rentre dans la phase de maintenance continue du système en
production. Pour ne pas perturber l’activité de qualification et de certification, nous avons
défini un troisième circuit de livraison appelé circuit HOTFIX. Ce circuit se veut être
entièrement disponible, sécurisé et rapide pour prendre en charge toute demande de
changement urgente et assurer sa mise en production dans les meilleures conditions, sans
provoquer de nouvelles régressions.

d. Cohérence des environnements logiciels.

A chaque fois qu’un changement est appliqué sur le système en production, qu’il soit HOTFIX
ou release, une action d’harmonisation est lancée automatiquement pour assurer la

6
Développement IT – Méthodes et Outils

cohérence des composantes applicatives en cours de développement, sur les divers

environnements de travail constituant l’infrastructure des circuits de livraisons.

Environnements T24 : infrastructure des circuits de livraisons, sujet de cohérence.

e. Intégration du mode AGILE

Comme cité plus haut, les projets sont souvent des projets de gestion, qui se basent sur des
processus métiers souvent très longs et qui ne peuvent être facilement subdivisés en sous
modules significatifs (MVP).

A l’arrivé du projet digital MYBIAT, il était question d’adapter le processus CI/CD OVTOOLS
pour synchroniser les développement front (gérés par une équipe externe VALUE) avec les
développements backend (gérés par l’équipe BIAT). Un nouveau circuit est défini pour gérer
la certification (UAT) des produits digitaux qui ne peuvent être planifiés dans les releases
backend de la banque. Pour des besoins d’économie des ressources machines, la phase de
qualification des produits digitaux est mutualisée sur le même circuit projet backend. Ainsi,
lorsqu’il est décidé de passer un produit digital d’une phase de qualification à une phase de
certification, ce dernier sera remonté vers le circuit digital, en passant par des contrôles
automatiques d’intersection, pour garantir son étanchéité par rapport aux projets backend.

IV. Modélisation de la solution release management

Pour s’adapter à la méthodologie de gestion de projet choisie plus haut, nous avons définie
des processus et des règles bien définies qui règlementent la transition et la synchronisation
des taches ou actions de prise en charge des changements et de leur mise en production.

7
Développement IT – Méthodes et Outils

Des circuits de livraisons qu’on peut aussi appeler Stream ou pipelines, sont définis pour
assurer la transition et la synchronisation des services allant de la conception au
développement et à la maintenance des systèmes :

• Circuit Projet : Organise l’activité de démarrage des changements des projets

planifiés ou produits digitaux jusqu’à leurs qualifications.
• Circuit Release : Organise l’activité de certification des changements des
projets jusqu’à la recette définitive
• Circuit HOTFIX : Organise l’activité de gestion des incidents des systèmes en
production
• Circuit Digital : Organise l’activité de certification des changements des
produits digitaux.
Un circuit de livraison, est constitué d’un ensemble d’environnements softwares portant une
même version du système et un ensemble de règles organisant l’activité de prise en charge et
de livraison des changements. Dans chaque circuit de livraison, nous retrouvons
essentiellement trois environnements softwares :

• Un environnement de développement (activité de développement, tests

unitaires)
• Un environnement d’assemblage ou bac à sable (activité de contrôle de
changement, d’intégration)
• Un ou plusieurs environnements de test (activité de tests fonctionnels)
a. Environnement de production :
L’environnement de production, est celui qui héberge la version finale du projet software en
production telle que validée par les métiers. Les seuls acteurs autorisés à y appliquer des
changements, sont les intégrateurs finaux, responsables de la production. Il ne peut être
alimenté que par des changements validés, provenant des circuits HOTFIX ou Release.
Au même niveau que l’environnement de production, nous retrouvons trois autres
environnements portant la même version applicative :

• L’Environnement RAP : Iso PROD, pour la génération de rapport et des

traitements batch (solution pour alléger la charge sur l’environnement
principal de production).
• L’Environnement INV : pour investigation suite à la détection d’incident.
• L’Environnement INTG : servant de référence applicative pour
l’environnement de production.

b. Référentiel de versions :
Tous les changements apportés sur le système en cours de développement ou en maintenance
sur la production, sont versionnés dans un référentiel de versions SVN. Un référentiel qui
centralise l’historique des changements et la version finale du système pour les besoins de
contrôle et la mise à disposition des bonnes versions.

8
Développement IT – Méthodes et Outils

Le référentiel de version est organisé sous forme de branches de versions. Nous retrouvons
autant de branches que de circuits de livraisons. Une branche de versions est définie pour
centraliser et versionner les changements effectués sur un circuit de livraison. A la réception
d’une livraison, un processus de versionning est déclenché automatiquement, pour versionner
le package applicatif sur la branche dédiée avec un versionning complémentaire sur une
branche associée au projet indiqué sur le ticket. Avec cette architecture de dépôt, il devient
possible d’observer les changements apportés sur une release, comme sur un projet
particulier. Ce qui offrira une solution rapide pour extraire ou rajouter un projet à une release
en cours de qualification en présence d’un système centralisé.

L’architecture adoptée pour le dépôt de versionning, permet de retrouver aussi rapidement

les versions les plus éloignées dans le temps pour tout objets, pour tout projet et pour toute
release. Il s’agit d’une architecture flexible qui permet d’identifier le périmètre applicatif de
tout projet, même s’il est embarqué avec un ensemble de projets dans une même release.
Cela constitue un avantage important pour pouvoir retirer des projets d’une release dans sa
phase de qualification sur décision PMO, tout en assurant sa cohérence.

9
Développement IT – Méthodes et Outils

Pour résoudre le problème des formats non textuelles présenté par l’architecture du système
T24, nous avons intégré un convertisseur « PACK MAN » fournit par l’éditeur TEMENOS avec
des adaptations appropriées pour pouvoir extraire un enregistrement de la base de données
non SQL (un objet T24 BLOB) et de le transformer en fichier texte tout en veillant à respecter
l’ordre d’affichage des champs au niveau des écrans WEB T24. Ce qui a rendu possible le
versionning du code applicatif du système T24 via un dépôt SVN. L’opération inverse aussi
délicate, est également réussie pour assurer le déploiement d’un objet textuel vers un
RECORD BLOB.
Ci-dessous un exemple d’écran de saisie ou VERSION T24, telle qu’affichée au niveau browser
WEB. Cet écran est enregistré sous forme d’un enregistrement BLOB dans la base de données :

10
Développement IT – Méthodes et Outils

Dans la représentation, ci-dessous, la même VERSION est transformée par l’outil PACKMAN
en fichier texte, ce que rend possible le versionning sur le dépôt de versions :

11
Développement IT – Méthodes et Outils

c. Transition de tâches opérationnelles sur les circuits de livraisons :

d. Rôles et activités par circuit de livraison :

i) Circuit HOTFIX :

FIGURE 1. CIRCUIT HOTFIX

12
Développement IT – Méthodes et Outils

ii) Circuit Release (Idem pour Digital) :

FIGURE 2. CIRCUIT RELEASE

iii) Circuit Projet :

FIGURE 3. CIRCUIT PROJET

13
Développement IT – Méthodes et Outils

e. Schéma global de fonctionnement

FIGURE 4. SCHEMA GLOBAL DE FONCTIONNEMENT

f. Schéma global de gestion des incidents (HOTFIX)

Lorsqu’un problème est constaté sur le fonctionnement du système en production, une

demande d’intervention sera communiquée par l’utilisateur final vers l’équipe Helpdesk pour
une première tentative de résolution. Si le problème nécessite, une intervention corrective
sur le système, la demande sera escaladée au niveau MOA (représentants métiers) pour plus
d’analyse et investigation sur l’environnement INV iso PROD. Le problème, peut porter sur la
correction des données, d’où un ticket TRAC de type « ACTION A CHAUT » sera défini à
destination de l’équipe production pour intervention. Si le problème porte sur la correction
du code applicatif, un ticket de type HOTFIX sera défini avec signalisation d’un motif
d’urgence. Le ticket HOTFIX, passera par une étape d’arbitrage par un représentant MOA et
un responsable développement pour valider l’urgence signalée. Auquel cas, le développement
du correctif doit être lancé de suite pour qu’il soit embarquer dans le circuit HOTFIX, ou que
la demande doit être différée dans une mini release ou une release.

14
Développement IT – Méthodes et Outils

FIGURE 5.SCHEMA GLOBAL DE PRISE EN CHARGE D’UNE DEMANDE CORRECTIVE

Lorsque la demande corrective est confirmée par le représentant MOA et le représentant DEV, pour
qu’elle soit traitée sur le circuit HOTFIX, un ticket de livraison est créé automatiquement et adressé
au développeur pour procéder à la livraison du correctif. Le livrable suivra le processus Delivery sur le
circuit HOTFIX (développement, packaging, versionning, déploiement, tests de qualification). Lorsque
le correctif est validé, une notification automatique est envoyée au responsable DSI pour donner son
accord pour l’appliquer sur la PROD. Une dernière vérification est toujours assurée par l’équipe
méthode et outils sur le statut des tickets validés avant de les transférer à l’équipe de production.
Ces contrôles et ces vérifications sont pilotés par des processus automatiques selon un workflow
soutenu par des alertes, des notifications et des tableaux de bord fournis par la plateforme
OVTOOLS.

15
Développement IT – Méthodes et Outils

FIGURE 6 SCHEMA GLOBAL DE TRAITEMENT D’UNE DEMANDE D’UN HOTFIX

V. OVTOOLS : Plateforme de pilotage de la solution release management.

Une plateforme OVTOOLS (un ensemble de développements locaux couplé des outils open
source tels que l’outil de ticketing TRAC et de versionning SVN) a été conçue et développée
par l’équipe méthodes et outils, pour orchestrer les diverses activités opérationnelles sur les
différents circuits de livraisons tels que définis plus haut et conformément à un Workflow
configurable dont le but principal est d’assurer les mises en production de tous les
changements selon une excellente réactivité et de manière bien sécurisée. Ci-dessous un
schéma décrivant l’architecture globale de la solution OVTOOLS :

16
Développement IT – Méthodes et Outils

FIGURE 7. ARCHITECTURE DE LA PLATEFORME OVTOOLS

OVTOOLS, ne se limite pas sur l’industrialisation des processus de déploiement et d’intégration

continue des livraisons. Il fournit aussi, des services qui offrent aux différents acteurs du projet des
raccourcis d’accès à l’information IT et son historique, des tableaux de bord bien adaptés pour suivre
l’avancements des tâches associées aux acteurs projets. OVTOOLS, permet aussi d’exécuter de
manière autonome le redéploiement des livraisons sur des environnements choisis pour tests en
dehors du workflow des circuits de livraisons pour des cas particuliers de tests. Ainsi, la plateforme
OVTOOLS, est conçue dans une logique d’un ITSM qui se charge de la cohésion de l’équipe projet. Des
services d’accès à diverses versions de l’information, sauvegardé dans le dépôt de versions permettent
d’offrir un travail en mode collaboratif. Elle assure le recensement des informations massives depuis
un seul endroit afin de tout gérer selon une meilleure réactivité et une transparence totale. En effet, il
devient possible de savoir à tout instant qui fait quoi ? quand et comment ?

NB : vous trouverez les fiches techniques des outils TRAC et SVN en annexe

17
Développement IT – Méthodes et Outils

a) Accès aux environnements et circuits de livraisons

Parmi les écrans OVTOOLS, nous retrouvons l’écran intitulé « Accès aux environnements et circuits
de livraisons », qui offre un raccourci d’accès aux différents environnement et circuit de livraisons.

FIGURE 8. OVTOOLS : TABLEAU DE BORD DES ENVIRONNEMENTS / CIRCUITS DE LIVRAISONS

b) Pilotage des taches opérationnelles par circuit de livraison :

Les activités opérationnelles, sont définies dans les tickets TRAC, affectés aux acteurs
responsables pour l’exécution des tâches qui lui sont associées. Dans le tableau de bord
ci-dessous, extrait de la plateforme OVTOOLS, il est possible d’observer les différentes
taches en attentes d’exécution ou de prise en charge par projet et par circuit de livraison :

FIGURE 9. OVTOOLS : VUE CONSOLIDEE DES ACTIVITES OPERATIONNELLES

c) Pilotage et Workflow.
Les changements apportés sur les systèmes en cours de construction ou en phase de
maintenance sont pilotés par un workflow retraçant une succession de taches opérationnelles
18
Développement IT – Méthodes et Outils

à réaliser par les différents experts conformément à une procédure WF bien définie. Cette
procédure doit contrôler et définir précisément toutes les étapes à suivre entre la première
phase de réception d’une demande de changement jusqu’à la dernière phase de mise en
production.
Le workflow d’activités se base sur un bordereau électronique représenté par un ticket TRAC,
retraçant la demande du changement et assure son aiguillage au bon destinataire selon le bon
circuit HOTFIX, PROJET ou RELEASE en fonction de la nature du traitement (bug ou
amélioration planifiée). Une piste d’audit intégrée dans l’outil TRAC, permet de suivre
l’historique des opérations d’intégrations des livraisons le long du cycle de vie du projet.

d) Processus de mise en production :

A chaque changement du statut du ticket TRAC, une nouvelle tâche opérationnelle est
déclenchée par l’outil OVTOOLS via des processus automatisés conformément à un workflow
configurable :

• Initier une demande de changement : le responsable MOA (représentant métier)

déclenche une demande de changement par la création d’un ticket TRAC où il
décrit l’origine du changement (SPEC/correctif).

FIGURE 10. EXEMPLE DE TICKET TRAC

• Prise en charge de la demande : le responsable développement, dispose d’un

tableau de bord sur l’outil OVTOOLS (couplé avec l’outil TRAC : pilotage de
l’activité Delivery), où il retrouve toutes les demandes de livraisons qui lui sont
affectées par circuit de livraison. Après analyse de la demande sur le ticket TRAC,
deux cas se présentent :

19
Développement IT – Méthodes et Outils

➢ La demande exige le retour immédiat de version du code ou de

paramétrage, le développeur peut revenir vers le responsable
OV pour disposer de la version antérieure et préparer le plan de
roll back

➢ Procéder à la génération du nouveau code et les tests unitaires

sur l’environnement de développement.

FIGURE 11.OVTOOLS : TABLEAU DE BORD DES DEMANDES DE LIVRAISONS PAR ACTEUR ET PAR CIRCUIT DE LIVRAISON

• Livrer pour assemblage ou packaging : Dès que terminé, le développeur, renseigne

sur un écran OVTOOLS, les objets ou codes applicatifs relatif au ticket TRAC, ainsi
que les recommandations utiles à la bonne intégration du livrable. Un processus
automatique OVTOOLS, se déclenche pour extraire le code applicatif livré et
versionné, suivi d’une action de packaging, de contrôle de norme ensuite un
déploiement sur un environnement d’assemblage tel que décrit dans l’étape
suivante du workflow de livraisons. Le ticket est ensuite affecté automatiquement
au responsable d’intégration OV (le release manager).

FIGURE 12. OVTOOLS : DECRIRE LE LIVRABLE POUR UNE INTEGRATION AUTOMATIQUE

20
Développement IT – Méthodes et Outils

• Assembler et intégrer la livraison : Le livrable fournit dans le ticket TRAC, est pris
en charge automatiquement par l’outil OVTOOLS pour assurer une succession
d’étapes : de contrôles d’intégration (contrôles de cohérence et de norme par
rapport à l’architecture du système), de versionning et d’assemblage/build (via
des scripts bien adaptées).
Si l’action d’intégration se termine avec des erreurs d’assemblage, le ticket sera
retourné automatiquement au développeur, l’invitant à apporter les correctifs
nécessaires et de relivrer de nouveau le ticket.

FIGURE 13.OVTOOLS : ACTION D’INTEGRATION TERMINEE AVEC ERREUR, SIGNALEE SUR LE TICKET TRAC

Dans tous les cas, une notification automatique sera envoyée aux responsables
(développement/testeur) associé, l’invitant à y intervenir.

FIGURE 14. OVTOOLS : NOTIFICATION AUTOMATIQUE, PROBLEME DE DEPLOIEMENT

21
Développement IT – Méthodes et Outils

• Qualifier/certifier la livraison : Le responsable MOA procède au test manuel de

qualification ou certification et fournit les cas de tests aux responsables Test
Factory pour préparer et planifier les tests automatiques de non régressions.

FIGURE 15. OVTOOLS : NOTIFICATION AUTOMATIQUE, INFORMANT L’ACTEUR MOA QUE SA DEMANDE EST PRETE POUR TEST

• Planifier le déploiement du changement sur la PROD : Lorsqu’il s’agit d’un

correctif urgent représenté par une demande HOTFIX qualifié, le transfert du ticket
pour mise en production doit passer par une approbation du responsable DSI afin
de fixer le moment adéquat de son application sur la PROD. Une notification sera
envoyée à toutes les parties prenantes pour information.

FIGURE 16. OVTOOLS : NOTIFICATION AUTOMATIQUE DE PLANIFICATION DE MISE EN PROD.

22
Développement IT – Méthodes et Outils

Lorsqu’il s’agit des tickets relatifs à un projet planifié, la mise en production

s’effectue dans un cadre d’une release/mini release, qui doit passer par deux
phases de tests, de qualification et de certification en plus des tests automatiques
de non régressions.
Le niveau de maturité d’une release est atteint en fonction du résultat de
qualification ou de certification de tous les tickets associés à la release. Des
reporting appropriés via l’outil OVTOOLS, permettent au responsable PMO, de
suivre au quotidien l’avancement de la release pour piloter la mise en production
dans les meilleures conditions.

FIGURE 17. OVTOOLS : REPORTING AVANCEMENT DE LA QUALIFICATION DE RELEASE

23
Développement IT – Méthodes et Outils

• Appliquer le changement sur la PROD : le responsable production, dispose d’un

tableau de bord sur l’outil OVTOOLS, où il retrouve toutes les demandes validées
(HOTFIX, Release ou mini release) pour activer leurs mises en PROD. Le processus
de mise production est conçu à l’image du processus d’assemblage et ce pour
garantir la cohérence et l’intégrité du livrable.

FIGURE 18. OVTOOLS : TABLEAU DE BORD COMMANDANT LA MISE EN PROD DES LIVRAISONS QUALIFIEES.

24
Développement IT – Méthodes et Outils

• Communiquer les changements apportés sur la PROD :

Lorsque le responsable DSI, donne son accord pour qu’un HOTFIX qualifié, soit
appliqué sur la PROD, l’équipe Méthodes et Outils, consulte le tableau de bord
présenté plus haut et valide l’envoi des tickets vers l’équipe de production par simple
clique sur une icône indiquant un verrou. Le ticket passe dans la file suivante,
réservée pour l’équipe de production. Cette transition de taches sera accompagnée
par un message automatique de communication pour informer à plus haut échelle,
l’application du correctif sur la PROD :

FIGURE 19. OVTOOLS : MESSAGE DE NOTIFICATION AUTOMATIQUE DE COMMUNICATION DES CHANGEMENTS APPLIQUES SUR LA
PRODUCTION.

En plus du message de notification des changements apportés sur la PROD, il est

possible de consulter sur OVTOOLS, le journal des changements dans un intervalle de
temps :

25
Développement IT – Méthodes et Outils

FIGURE 20. OVTOOLS : TABLEAU DE BORD POUR LISTER LES CHANGEMENTS APPLIQUER SUR LA PROD DANS UN
INTERVALLE DE TEMPS.

• Harmoniser les environnements : A la suite de toute application de changements

sur la PROD, des processus automatiques se déclenchent via l’outil OVTOOLS, pour
diffuser la version objet des changements sur tous les environnements de
développement et de test. Cette diffusion de version est indispensable pour
garantir la cohérence et l’intégrité des environnements et réduire les risques de
régressions. Elle consiste à déterminer automatiquement les intersections ou
frottements entre les diverses versions de code portées par les environnements et
versionné dans le référentiel SVN. Toute intersection est synonyme de risque de
régression, pour laquelle une adaptation de code doit être livrée via un ticket TRAC
par le responsable développement selon le même processus Delivery.

26
Développement IT – Méthodes et Outils

FIGURE 21. OVTOOLS : TABLEAU DE BORD, LISTES DES TICKETS APPLIQUES SUR PROD A ADAPTER SUR LE RESTE DES
ENVIRONNEMENTS

Une notification sera envoyée au responsable développement pour accélérer les

adaptations et ajuster les versions de codes.

• Clôture du ticket : lorsque les changements demandés HOTFIX ou la release sont

appliqués sur la PROD et approuvés par les responsable MOA, le ou les tickets
associés seront automatiquement clôturés.

e) Remontée d’une release au circuit d’intégration à la production :

Comme décrit plus haut, au niveau de la partie Méthodologie de la gestion de changements, une
release ayant atteint un niveau de maturité, lui permettant de passer à la phase de certification ou
même en production, elle doit passer par une étape de contrôle automatique d’intersection dont le
référentiel reste toujours le dépôt de versions. Ce qui garantira l’intégrité de toute release.

Un processus d’étude d’intersection sera lancé, sur la branche SVN associée au circuit même où elle
est construite par rapports aux branches SVN des projets hors release. Les intersections détectées,
constituent une source de conflit de code qui peuvent constituer des risques de régressions.

Les intersections significatives détectées, sont tracées sur le ticket et égaillées automatiquement vers
le développeur responsable sur le projet. Les adaptations nécessaires d’ajustement de ces conflits sont
livrées par les développeurs à l’instar de tout changement. Une release ne peut intégrer la production
que lorsque tous les changements sont livrés et certifiés. Des tableaux de bord OVTOOLS permettent
aux équipes PMO et MOA de suivre l’avancement de la certification des releases jusqu’à sa mise en
production.

27
Développement IT – Méthodes et Outils

FIGURE 22. OVTOOLS : RESULTAT D'ETUDE D'INTERSECTION

f) Contrôle et investigation sur les changements :

L’outil TRAC, intégré dans la plateforme OVTOOLS, fournit une arborescence qui retrace
l’architecture du dépôt de versions. Il offre, des outils d’accès à la version la plus éloignée dans le
temps pour information.

Il est possible de visualiser rapidement, le différentiel de changement entre deux versions d’un
même objet comme pour un projet ou une release entière.

28
Développement IT – Méthodes et Outils

g) Reporting sur les changements planifiés :

La plateforme OVTOOLS, fournit des Reporting permettant de visualiser les changements appliqués
sur la production ou en cours de tests. Ces informations, sont très utiles pour recenser l’ensemble de
réalisations des projets et des releases.

29
Développement IT – Méthodes et Outils

h) Base de connaissances :

Les méthodes et les solutions d’intégration identifiées le long des cycles de déploiement et
d’intégration des projets sont conservées dans une base de connaissances accessible par les experts
projet. Cette base est gérée par l’outil TRAC via une l’utilitaire WIKI.

FIGURE 23. EXTRAIT D'UNE PAGE WIKI

30
Développement IT – Méthodes et Outils

i) Niveau d’automatisation des taches opérationnelles : Projet T24:

Volume des taches opérationnelles sur les cinq dernières années : Projet T24

Niveau d’automatisation des taches opérationnelles : Projet T24

31
Développement IT – Méthodes et Outils

VI. Conclusion :
La solution release management ou gestion des mises en production est pilotée par la
plateforme OVTOOLS. Il s’agit d’une solution BIAT, conçue et développée par l’équipe
Méthodes et Outils. Elle se base sur une architecture hybride constituée par des circuits de
livraisons synchronisés pour gérer les applications développées en langage standards que
celles développées en langages spécifiques. La synchronisation de ces circuits est contrôlée
par un référentiel de gestion des versions et des processus d’harmonisation à l’occurrence de
toute mise en PROD d’une nouvelle release ou correctif élémentaire.
Des processus IT sont définis et développés pour orchestrer les différentes phases : la
planification, le développement, les tests, la préparation et le déploiement d’une mise à jour
logiciel. Ces processus, intégrés dans des workflows configurables, permettent de garantir une
activité continue et rapide de prise en charge des demandes de changement et de leurs
applications définitives sur les systèmes en production.
La plateforme OVTOOLS est conçue dans une logique d’ITSM, qui se concentre sur les besoins
des acteurs projet. En effet, elle se charge de la cohésion de l’équipe projet et le recensement
des informations massives depuis un seul endroit. Une même base donnée OVTTOLS, qui
renseigne sur toutes les informations échangées par l’équipe projet.
Les changements appliqués sur les environnements de production (PROD) sont effectués
conformément à une procédure release management bien définie. Où des principes clés issus
des bonnes pratiques ITIL, sont introduits pour garantir la sécurité des systèmes en production
contre toute régression possible. Il s’agit de séparer les rôles et définir des règles précises pour
la gestion des tâches opérationnelles. Parmi ces ses principes nous retrouvons :
➢ Seuls les responsables de production, qui sont autorisés à déployer des changements
validés sur la PROD.
➢ Aucune mise à jour ne doit être appliquée sur la PROD, si elle n’est pas fondée et
validée par les métiers. Un système de ticketing et dépôt de versions sont intégrés
pour tracer et documenter les demandes et y garder la trace des changements.
➢ Tout ticket de livraison envoyé vers la PROD, doit faire l’objet d’une série de tests
techniques et fonctionnels :
o Unitaire, sur un environnement de développement
o Assemblage, sur un environnement d’assemblage
o Fonctionnel de qualification et de certification, sur un environnement de test
La solution release management, permet de maitriser les changements et de sécuriser les
mises à jour en production. Le dépôt de versions, constitue un patrimoine applicatif pour la
banque qui détient le cycle de vie du système. Un historique de versionning, qui remonte à
plus que 11 ans.
La solution OVTOOLS, rend l’information disponible et facile à obtenir puisque tout est
conservé dans une même base. La solution est conçue dans une logique extensible grâce à
une couche de configurable très approfondie, ce qui lui permet de s’adapter aux orientations
de la banque pour contribuer à la création des valeurs et suivre les nouvelles transformations
technologiques.
32
 Développement IT – Méthodes et Outils

I. Caractéristiques techniques des outils TRAC et Subversion:

1. TRAC

Trac est un système WEB de gestion de projets de développements logiciels. Il

appartient au monde libre (Open Source) :

− Site officiel : http://trac.edgewall.org/

− Développé en : langage Python
− Développé par : Edgewal, une jeune société spécialisée dans l’Open-Source et
Linux.

− Base de données : propriétaire, SQLITE (par défaut) ou PostgreSQL.

− Outils supplémentaires :
• Trac sous solaris 10 SPARC (> 0.10.x) ou WINDOWS
• Clearsilver pour la modélisation des pages HTML. (>= 0.10.x)
• Python, compilateur des packages sources (>=2.x)
• Subversion (>= 1.4.5)
• Subversion SWIG Python bindings (non PySVN).
• PySQLite, version 1.x (pour SQLite 2.x) ou la version 2.x (pour SQLite 3.x)
n’est pas nécessaire pour le cas de BD de type Berkeley
• SWIG (>= 1.3.x)
• SQlite (> 3.x)
• Enscript ( >1.6.x)
• Un serveur Web capable d’exécuter les scripts CGI/FastCGI, ou Apache
HTTPD avec le mode mod_python.
− OS.......: multiplateforme
− Langue…….. : anglais
− Taille …. < 500Ko
− Licence …….. : GNU General Public License

33
Développement IT – Méthodes et Outils

2. SUBVERSION

Subversion est un système de contrôle des versions Open Source.

− Site officiel : http://subversion.tigris.org/

− Subversion est écrit en langage python

− Développé et soutenu par Collabnet
(http://www.collab.net)
− Interface graphique : client lourds (TortoiseSVN pour
WINDOWS ou Rapidsvn pour typeUNIX)
− Il utilise comme méthode d’accès réseau trois protocoles (svn, svn+ssh et
http).

− Pour utiliser Apache comme serveur réseau, il doit intégrer un protocole

Web/DAV/DeltaV basé sur HTTP.
− Base de données système de fichiers SQLITE ou de type Berkeley

− OS.......: multiplateforme
− Licence compatible Apache/BSD
− Langue…….. : anglais
− Taille …. < 11.6 MB

34
Développement IT – Méthodes et Outils

• Référentiel de contraintes d’intégrité 1

35
Développement IT – Méthodes et Outils

• Référentiel des APIs 2

36
Développement IT – Méthodes et Outils

• Référentiel des environnements 3

37
Développement IT – Méthodes et Outils

• Référentiel des projets 4

38
Développement IT – Méthodes et Outils

Annexe

(1) http://172.28.70.74:8090/OVTOOLS/AdministrationContraintesIntegrite.do
(2) http://172.28.70.74:8090/OVTOOLS/ListDesAPI.do
(3) http://172.28.70.74:8090/OVTOOLS/GestionBaseDonnesParametrages.do?admin=gestionDe
sEnvironnements
(4) http://172.28.70.74:8090/OVTOOLS/planProjetsParAnee.do

39