Vous êtes sur la page 1sur 15

Direction Générale de l'Administration

Direction des Technologies de l'Information

NORMES
PROCÉDURE DE LIVRAISON

Type de document :
 projet
à valider
 validé

Référence : 415689207.doc

Objectif du document

Ce document a pour objectif de décrire la


procédure de livraison d’une application au
Conseil de l’Europe.

1
415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 1 / 16
Normes
Procédure de livraison

Ce document est la propriété du Conseil de L’Europe.


Il ne peut être reproduit ou communiqué sans accord préalable de l’auteur.

Sommaire

OBJECTIF DU DOCUMENT...........................................................................................1

1. INTRODUCTION...............................................................................................3
1.1 Signalétique...............................................................................................3
1.2 Lexique.....................................................................................................3
2. OUTILS UTILISÉS PAR LE COE............................................................................4
3. PRÉREQUIS D’UNE LIVRAISON............................................................................4

3.1 Accès au gestionnaire des Sources................................................................4


3.2 Accès et utilisation du gestionnaire de suivi de sollicitation Metro......................4
4. PRÉSENTATION DES DIFFÉRENTS ENVIRONNEMENTS................................................5

5. CONTENU D’UNE LIVRAISON...............................................................................6

5.1 Contenu du bordereau de livraison................................................................6


5.1.1 Pour la marche à suivre, il est indispensable de préciser dans la description :..........6
5.1.2 Les modifications des fichiers de configuration.....................................................7
5.1.3 Les informations complémentaires.....................................................................7
5.1.4 Cas des scripts pour MSSQL..............................................................................7

5.2 Éléments à livrer........................................................................................8


5.2.1 Fichiers source................................................................................................8
5.2.2 Documentation...............................................................................................9
5.3 Cas Spécifique d’un Patch..........................................................................10
6. RESPECT DES NORMES....................................................................................11

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 1 / 16
Normes
Procédure de livraison

6.1 Développement........................................................................................11
6.1.1 Particularité pour les applications .Net..............................................................11

6.2 Documentation.........................................................................................12
7. Gestion des Versions.....................................................................................12

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 2 / 16
Normes
Procédure de livraison

1. INTRODUCTION

Le système de gestion de configuration du Conseil de l’Europe permet de stocker


l’ensemble des sources et des documents relatifs à chaque application. Il utilise la
technologie Subversion (SVN).
Toute livraison au Conseil de l’Europe devra être effectuée par ce biais-là.

Chaque application dispose de son propre espace de stockage. Cet espace réservé
est nommé dépôt.

La procédure de livraison est valable pour toute livraison d’une application, quelle
que soit son importance : qu’il s’agisse d’une correction, d’un dysfonctionnement, d’une
évolution mineure ou majeure, etc..

La procédure décrite dans ce document devra être respectée, sous peine


de rejet ou d’ajournement de la livraison effectuée

1.1 SIGNALÉTIQUE

Tout au long de ce document, les pictogrammes ci-dessous sont utilisés afin de souligner
des points ou des notions importantes.

Information importante

Action spécifique

Action à éviter

Action obligatoire

1.2 LEXIQUE
CoE : Conseil de l’Europe
SVN : Subversion
Projet : Toute évolution d’une application quelle que soit sa taille (y compris une
correction)
SLA : Service Level Agreement ou “Contrat de Niveau de Service”. SLA est utilisé, en
référence au temps de délivrance et/ou à la performance (du service) tel que
défini dans le contrat
BL : Bordereau de Livraison
DI : Dossier d’Installation
DE : Dossier d’Exploitation
MU : Manuel Utilisateur

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 3 / 16
Normes
Procédure de livraison

2. OUTILS UTILISÉS PAR LE COE

Pour le développement et les tests de ses applications, le CoE utilise un certain nombre
d’outils.
Le Fournisseur devra se conformer à l’utilisation de ces outils.

Les outils obligatoires sont :

 Metro : système de suivi de bug basé sur Mantis (Outils de BugTracker)


 Subversion : système de gestion de configuration
 Djinn : Interface Web pour effectuer les livraisons
 UAT (Testlink) : outil de gestion de tests

Les méthodes recommandés sont

 UML : langage graphique de modélisation des données et des traitements.

3. PRÉREQUIS D’UNE LIVRAISON

3.1 ACCÈS AU GESTIONNAIRE DES SOURCES

Tout fournisseur développant une nouvelle version d’une application du CoE


devra, au préalable, s’assurer qu’il dispose d’un accès aux sources de l’application via
SVN.
L’accès à SVN lui sera fourni au démarrage du projet (corrections, évolutions…) via le
Coordinateur du projet (« Professional Lead »).

Cet accès comportera :


 L’adresse du dépôt à utiliser sous la forme ;
http://vesioning.coe.int/svn/MonApplication/branches/z.y.x )
 La liste des utilisateurs autorisés à effectuer des modifications.

En cas de régression survenue lors d’une nouvelle livraison, la charge sera à l’actif du
Fournisseur.

3.2 ACCÈS ET UTILISATION DU GESTIONNAIRE DE SUIVI DE


SOLLICITATION METRO

Tout Fournisseur doit utiliser le gestionnaire de suivi de sollicitations Metro :


https://metro.coe.int

Les droits d'accès à Metro seront créés au début du projet et communiqués au chef de
projet du Conseil de l'Europe.

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 4 / 16
Normes
Procédure de livraison

Toutes les demandes de changement, de corrections ou d'évolutions d'une application


doivent être directement saisies dans Metro par les utilisateurs ou les gestionnaires de
l'application concernée. Les demandes sont ensuite analysées et transmises au
fournisseur en charge du développement ou de la maintenance de l'application. Le
fournisseur reçoit un mail d'alerte pour chaque demande individuelle.

4. PRÉSENTATION DES DIFFÉRENTS


ENVIRONNEMENTS

Le Conseil de l’Europe dispose de plusieurs environnements pour valider les applications.

 Environnement de livraison (LIV) : optionnel


Cet environnement permet d'effectuer la recette technique de la livraison et de
valider le bon fonctionnement de l'application en réalisant les tests unitaires avant
l'installation de l'application sur la plateforme de validation. Il est utilisé
uniquement pas les équipes qui déploient l’application.

 Environnement de validation (VAL)


Environnement permettant de valider fonctionnellement l'application en réalisant
les tests fonctionnels (UAT - User Acceptance Testing) liés aux évolutions et
corrections de la nouvelle version de l'application avant de l'installer sur la plate-
forme de production.

 Environnement de production (PROD)


Environnement permettant de faire la recette finale et qui permet aux utilisateurs
d'utiliser/essayer les applications hébergées. Contrairement aux autres
environnements, la production est soumise à un SLA qui permet de garantir un
certain niveau de disponibilité des applications hébergées.

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 5 / 16
Normes
Procédure de livraison

5. CONTENU D’UNE LIVRAISON

Toute livraison doit obligatoirement être accompagnée d’un BL

Toute livraison sera matérialisée par un BL (Bordereau de Livraison). Ce BL sera créé via
l’interface : http://djinn.coe.int/_home. Si les développeurs n’ont pas les accès à cette
Url , il leur faudra alors les demander au Coordinateur du Projet.

5.1 CONTENU DU BORDEREAU DE LIVRAISON

Aperçu de l’interface de livraison :

La note relative à la livraison comprendra les informations suivantes :

 Marche à suivre pour le déploiement (code/rapports à déployer, indexation à


lancer...)
 Liste des scripts SQL à exécuter
 Modifications des fichiers de configuration
 Informations complémentaires si nécessaires

Le numéro du Ticket d’intégration doit correspondre au numéro du ticket relatif à cette


livraison.

5.1.1 POUR LA MARCHE À SUIVRE, IL EST INDISPENSABLE DE


PRÉCISER DANS LA DESCRIPTION :

 les différentes briques de l’application à déployer : SQL , SiteWeb,


Rapports, exécutable schedulé, service NT...
 les nouveaux modules à déployer (Service NT, nouvel Exe à planifier…)

En résumé tout ce qui est nécessaire au bon fonctionnement de l’application.

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 6 / 16
Normes
Procédure de livraison

5.1.2 LES MODIFICATIONS DES FICHIERS DE CONFIGURATION

 Elles correspondent aux opérations effectuées sur les fichiers de


configuration (app.config, web.config). Dans ce cas, il est nécessaire de
décrire explicitement les modifications du ou des fichiers de configuration.
Pour la première livraison d’un projet, la personne qui déploie l’application
se basera sur le fichier de configuration présent sous contrôle de source.
Pour les livraisons suivantes toutes les modifications devront être
présentes dans le BL sans quoi elles ne seront pas prise en compte (la DI
devra également être mise à jour).

5.1.3 LES INFORMATIONS COMPLÉMENTAIRES


Elles servent par exemple à préciser si des modifications d’architecture sont
nécessaires
ex. : Création d’un nouveau partage réseau (Share) ou modification d’ACL-s
(Access Control Lists), chronologie des tâches à réaliser si nécessaire, exécution
de tel ou tel exécutable, import de données, nouveau web service, nouveau
rapport Reporting Services à déployer, librairies à installer…

5.1.4 CAS DES SCRIPTS POUR MSSQL

Ci-dessous, la structure des répertoires pour la partie MSSQL :

La règle lors d’un déploiement (MEL, MEV, MEP) est la suivante :

Les scripts seront exécutés dans l’ordre suivant, en fonction des instructions du BL :

1. Tables
2. Views
3. Stored Procedures
4. Queries
5. Functions

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 7 / 16
Normes
Procédure de livraison

Cette procédure convient pour la majorité des déploiements en raison des points
suivants :

1. Après chaque mise en production, la personne qui fait le déploiement déplace


les scripts qui se trouvent à la racine des répertoires Queries, Tables et Views
dans un répertoire nommé : MEP_NumeroTicketIntegration (Queries\
MEP_NumeroTicketIntegration, Tables\ MEP_NumeroTicketIntegration, Views\
MEP_NumeroTicketIntegration) afin de s’assurer de ne pas les repasser lors de
l’intégration Future.

2. Les scripts de création de procédures et de fonctions sont exécutés lors de


chaque déploiement et contiennent les instructions Drop, Create (cf
Norme de développement).

3. Tous les scripts doivent être numérotés comme cela est spécifié dans les
normes de développement. Les scripts seront exécutés dans l’ordre de la
numérotation.

4. Lors du déploiement, un programme concatène les scripts SQL précisés dans


le BL (Tables, Views, Stored Procedures, Functions, Queries) puis les exécute
dans l’ordre précisé ci-dessus sur la Base.

Si une de ces règles ne peut être respectée, alors il est nécessaire de


préciser exactement les scripts à exécuter et dans quel ordre lors de la
livraison.

5.2 ÉLÉMENTS À LIVRER

5.2.1 FICHIERS SOURCE

Il s’agit de l’ensemble des fichiers sources représentant l’application complète, telle


qu’elle aura été vérifiée et validée par le Fournisseur au cours de ses tests de recette. Y
sont inclus les scripts SQL de modification de structure et d’import de données, les
rapports, etc.

Seuls les fichiers sources nécessaires au bon fonctionnement de


l’application ainsi que la documentation sont à remonter dans le dépôt.

5.2.1.1 Applications .NET

Les outils de développement des applications .NET (Microsoft Visual Studio) génèrent un
certain nombre de fichiers et/ou de répertoires qu’il n’est pas souhaitable de versionner.

Les éléments suivants ne doivent pas être ajoutés au sein du dépôt de l’application :

 Les répertoires bin et obj générés par la compilation de l’application ;


 Les fichiers .user, .suo, .webinfo ;

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 8 / 16
Normes
Procédure de livraison

 Les fichiers .data des projets « Reporting Services » permettant de gérer le cache
de données lors de l’affichage des rapports ;
 Les fichiers générés par d’autres gestionnaires de sources, propre au fournisseur ;
 Les répertoires et fichiers générés par tout outil utilisé par le fournisseur
(extension FrontPage, …).

5.2.1.2 Applications Java


Les outils de développement des applications Java (Eclipse) génèrent un certain nombre
de fichiers et/ou de répertoires qu’il n’est pas souhaitable de versionner.

Les éléments suivants ne doivent pas être ajoutés au sein du dépôt de l’application :

 Les répertoires WEB-INF\classes


 Les fichiers .class

5.2.2 DOCUMENTATION

Les documents décrivant l’application sont présents au sein du système de gestion de


configuration Subversion. Ils se trouvent dans le répertoire « Documentation » à la
racine du dépôt.

Les documents obligatoires dans ce répertoire sont :

 SFD – Spécifications Fonctionnelles Détaillées ;


 DI – Dossier d’Installation ;
 DAT – Dossier d’Architecture ;
 MU – Manuel Utilisateur ;
 ST – Spécifications Techniques.

Les documents recommandés sont :


 PAQ – Plan d’Assurance Qualité ;
 TU – Plan de Tests Unitaires ;
 RT – Rapport de Tests.

Afin d’assurer la cohérence de l’ensemble de la documentation au regard de la version


livrée, le fournisseur devra obligatoirement mettre à jour l’ensemble des documents
impactés par les modifications qui lui ont été demandées.
La mise à jour des documents doit être globale et ne pas se résumer à des nouveaux
paragraphes juxtaposés listant les différentes modifications.

Le fournisseur est également tenu d’expliciter les évolutions des autres modules qui ont
été impactés par les modifications effectuées sur l’application.

Exemple : Lorsqu’une correction est effectuée sur le module A de l’application, elle doit
être documentée. Les explications regrouperont l’ensemble des informations
(fonctionnelles, techniques, etc.) relatives à ce module. Il est obligatoire de documenter
tous les modules connexes à celui-ci de la même manière.

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 9 / 16
Normes
Procédure de livraison

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 10 / 16
Normes
Procédure de livraison

5.3 CAS SPÉCIFIQUE D’UN PATCH

Un Patch est un ensemble de 1 ou 2 correctifs à passer en production rapidement.


Si un développement est en cours sur le trunk, les correctifs seront à « commiter » sur
une version du code correspondant à la version actuellement en production, c’est-à-dire
sur la branche y.z.x utilisée pour le dernier déploiement en production. Dans ce cas, les
droits ainsi que le numéro de la branche sur laquelle le développeur doit « commiter »
ses modifications lui seront communiqués soit par l’intégrateur soit pas le coordinateur
DIT.

Il appartiendra au développeur de répercuter les modifications effectuées pour ce


patch sur le trunk. En effet s’il ne le fait pas, ces modifications ne seraient pas prise en
compte lors du déploiement suivant étant donné qu’il se fera à partir d’une révision du
trunk.

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 11 / 16
Normes
Procédure de livraison

6. RESPECT DES NORMES

6.1 DÉVELOPPEMENT

Au démarrage du projet :

 Le Coordinateur du projet (« Professional Lead ») s’engage à fournir tous les


éléments (normes de développement et versions à jour des documents).

 Le Fournisseur s’engage à :
- Respecter les normes de développement en vigueur au CoE ;
- S’assurer d’être en possession de la dernière version à des documents sur
les normes et standards de développement : http://vdd.coe.int

Un ensemble de contrôles est effectué lors de la réception d’une livraison

A l’issue de cette analyse, la livraison sera, soit :

- Acceptée, et installée sur l’environnement de livraison du CoE

- Rejetée (voir et consulter les points de contrôle - cf. 1.2 du Modèle de Rapport
d’analyse pour les applications J2EE ou celui pour les applications .Net).

6.1.1 PARTICULARITÉ POUR LES APPLICATIONS .NET

Suite à la livraison, une analyse de code sera effectuée avec FXCop en plus du
rapport d’analyse manuel comme vu précédemment.

FXCop sera utilisé dans le cadre des rapports d’analyse.

Le CoE n’acceptera pas la livraison s’il y a des erreurs dont la probabilité


est supérieure ou égale à 80%. Pour les autres erreurs et les warnings, le CoE se
réserve la possibilité de demander des modifications selon l’importance de ces derniers.

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 12 / 16
Normes
Procédure de livraison

6.2 DOCUMENTATION

Au démarrage du projet :

 Le coordinateur du projet (« Professional Lead ») s’engage à fournir tous les


modèles de documents à utiliser au moment du démarrage du projet.

 Le fournisseur s’engage à :
- Respecter les modèles de documents utilisés par le CoE ;
- S’assurer qu’il est en possession de la dernière version des modèles de
document cités dans le paragraphe "5.2.2 Documentation"

Tous les chapitres doivent être renseignés. En aucun cas, un chapitre ne devra être
supprimé. Si celui-ci est non applicable dans le cadre de l’application, il devra être noté
comme tel (N/A).

Si toutefois, le fournisseur note une impossibilité de se conformer au modèle, car le(s)


chapitre(s) en question est (sont) inadapté(s), il devra le signaler au plus vite, et motiver
son « rejet ». Une adaptation du modèle pourra être proposée par le fournisseur pour les
chapitres et / ou l’application en question.

7. GESTION DES VERSIONS

La gestion des versions des applications diffère s’il s’agit d’une application :
- développée par le Conseil de l’Europe ou
- utilisée par le Conseil de l’Europe (logiciel du marché, application Open
Sources….) et pour laquelle celui-ci effectue des développements supplémentaires afin
de satisfaire pleinement les besoins fonctionnels.

Application développée par le Conseil de l’Europe

La numérotation de la version est décomposée en 3 chiffres représentés ici par : z.y.x

 z correspond à la version majeure de l’application. Il est incrémenté lors


d’évolution(s) majeure(s) de l’application. C’est le responsable applicatif en
collaboration avec le Coordinateur DIT qui choisit ce chiffre.

 y correspond à la version mineure de l’application. Il est incrémenté lors


d’évolution(s) mineure(s) ou d’incident(s) au sein de l’application. C’est le
responsable applicatif en collaboration avec le Coordinateur DIT qui choisit ce
chiffre.

 x est incrémenté automatiquement lors de chaque mise en livraison de


l’application ou de mise en validation si l’application ne possède pas
d’environnement de livraison. Il est également incrémenté lors d’un patch en
production, puisqu’au final un patch nécessite un nouveau déploiement et donc
d’une nouvelle mise en livraison ou d’une nouvelle mise en validation si
l’application ne possède pas d’environnement de livraison. Rappelons qu’un patch
est un déploiement en production de 1 ou 2 incidents nécessitant deux jours
ouvrés maximum entre la date de Livraison et date de Mise en Production.

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 13 / 16
Normes
Procédure de livraison

Application non développée par le conseil de L’Europe (logiciel du marché,


application Open Sources….)

La numérotation de la version est composée de 5 Chiffres représentés pas les lettres :


a.b.c.y.x

 Les chiffres représentés pas les lettres a.b.c, correspondent à la version du


logiciel utilisé

 Le chiffre représenté par la lettre y à la même définition que pour une application
développée par le CoE

 Le chiffre représenté par la lettre x à la même définition que pour une application
développée par le CoE

Fin du document

415689207.doc [Normes]
Dernière modification 04 février 2013 à 13:37:00
Auteur DIT / DD / W&S Version : 1.1 Page 14 / 16