Annexe 2 : standards techniques DSI Forem

Transcription

1 Table des matières 1 INTRODUCTION INVENTAIRE TECHNOLOGIQUE VUE GLOBALE DE L ARCHITECTURE DES APPLICATIONS ARCHITECTURE ESB STANDARDS DE DÉVELOPPEMENTS.NET STANDARDS DE DÉVELOPPEMENT J2EE STANDARDS DE DÉVELOPPEMENTS HTML/CSS/JAVASCRIPT MISE À JOUR DES DÉPENDANCES DOCUMENTATION DE DÉVELOPPEMENT STANDARDS DE DÉVELOPPEMENTS RELATIFS AUX SGBD STANDARDS DE DÉVELOPPEMENTS EN MATIÈRE DE SÉCURITÉ LES TYPES D'ENVIRONNEMENTS APPLICATIFS AU DSI Version du 17/11/2014 Page 1 sur 47 pages Dossier DMP /HTNMMN/EAI

2 1 Introduction La présente annexe décrit les standards techniques en vigueurs au DSI. Celle-ci donne une vue globale des technologies utilisées au Forem, de l architecture des applications et des standards en matière de développements. 2 Inventaire technologique 2.1 Applicatif Plateforme logicielle CaseWise OnMap SMS (Quescom) Webtrends Progiciel de gestion Archibus Chronos (IDTEC) Efficy Focus Data ABC Suite Genesis HR Access Ordiges PIA, EPM, ECO Plug RH (Groupe S) Vivaldi QMS 5.0 Modélisation des processus métier Outil de documentation des processus Envoi automatisé d'sms (Short Message Service) Outil d'analyse de statistiques de visites du site forem.be Progiciel gestion immobilière ( Progiciel gestion pointage & accès bâtiments ( Progiciel CRM ( Progiciel analyse ABC ( Progiciel de gestion du Call Center demandeur d'emploi Progiciel gestion des ressources humaines Progiciel comptabilité, gestion dépenses, économat ( Progiciel gestion des ressources humaines Progiciel de gestion de la qualité Version du 17/11/2014 Page 2 sur 47 pages Dossier DMP /HTNMMN/EAI

3 2.2 Développements Langage/boîte à outils.net Plateforme de développement de runtime Microsoft C# Langage de programmation EJB Architecture de composants Java J2EE Spécification pour la technologie Java Java Langage de programmation HTML/CSS/JavaScript Langages de développement front end NatStar Environnement de développement PHP Langage de programmation Outil/plateforme de développement Artifactory Binary Repository Manager pour Maven BIRT Générateur de documents BIRT Report Designer BIRT reports tools Eclipse (& Plugins) Environnement de développement Java Iplotz Mockup d'écran Jenkins Intégration continue Latex Moteur d'impression Maven Outil open-source de build pour les projets Java MS SQL Server Integration Service Transformation et chargement des données Oracle Warehouse Builder Transformation et chargement des données Sonar Mesure de la qualité du code source Team Foundation Server Forge logicielle et intégration continue pour les développements.net Visual Studio Environnement de développement.net Plateforme logicielle Apache Solr Plateforme de recherche Apache ActiveMQ Open source message broker Apache Camel Logiciel d'échange de messages entre application Apache ServiceMix Enterprise Service Bus Jira Bugs Tracker - Gestion des tâches Lucene-SolR Moteur de recherche Mantis Bugs Tracker Version du 17/11/2014 Page 3 sur 47 pages Dossier DMP /HTNMMN/EAI

4 2.3 Infrastructure Antivirus/Antispam FOPE Office 365 Fortinet Mc Afee SpamHouse Trend Micro Authentification Antivirus/antispam Mails Antivirus legacy pour applications externes Antivirus Antispam legacy pour les mails Antivirus - IMSS antivus legacy pour les mails entrants ADFS 2.0 Système d'authentification fédérée vers Office 365 Cisco ISE Evidian IAM Evidian SSO Microsoft Active Directory Oracle Sun One LDAP Shibboleth VASCO Server Automatisation/planification batchs BMC Control-M MS SCOR Backup EMC Legato EMC2 Networker Base de données Microsoft SQL Server MySQL Oracle DB Oracle SQL Data Modeler Oracle SQL Developer Sybase ASE Sybase IQ Tamino Gestion des accès réseaux des devices (Wifi) Gestion des identités et des accès Authentification unique Annuaire entreprise Annuaire entreprise Système d'authentification des utilsateurs du site Leforem.be Solution d'authentification complémentaire forte via token Solution pour la gestion des batchs applicatifs Module de Service Manager permettant d'automatiser des workflows Logiciel de Backup centralisé Solution de backup centralisé Base de données pour les solutions du windows Base de données pour petites solutions Base de données pour les applications Java Oracle db developement tools Oracle db developement tools Base de données Sybase pour applications legacy Erasme et IGFP base de données legacy base de données XML Version du 17/11/2014 Page 4 sur 47 pages Dossier DMP /HTNMMN/EAI

5 Toad BI/Reporting SAP Business Objects Microsoft BI Bureautique Internet Explorer IMAP Serveur Messagerie (SUN) Microsoft Exchange Microsoft Exchange Online (Office 365) Microsoft Lync (Office 365) Microsoft Office Pro Plus (Office 365) Microsoft OneDrive/MySite (Office 365) Microsoft Onenote (Office 365) Microsoft Outlook (Office 365) Microsoft Publisher (Office 365) MS SharePoint Online (Office 365) Microsoft Yammer (Office 365) Microsoft Office (KMS) Microsoft Visio Microsoft Project Microsoft Project Server Mind Manager Pro Mind Manager Viewer Enterprise Architect Isabel Publiweb APE Viscalc Segese Simul Performanse Aries Label Print Outil d'administration pour Oracle DB, Solaris Business Intelligence Business Intelligence Navigateur Internet Serveur de messagerie (utilisé pour le routage de mail) Solution serveur de Messagerie (utilisé pour le routage de mail) Serveur de messagerie Vidéo conférence et messagerie instantanée Suite bureautique de base pour les agents (Word,Excel,PowerPoint,Access) Espace personnel pour les agents Outil de prise de note pour les agents Client lourd de messagerie pour les agents Publication assistée par ordinateur Gestion et partage de fichiers Réseau social privé Suite bureautique pour les DE (via Citrix) Création de diagrammes Logiciel de gestion de projets Solution de gestion du portefeuille de projets Mind mapping software Viewer Mind mapping Modélisation UML Logiciel de gestion des paiements bancaires Logiciel de gestion des paiements bancaires Outil de visualisation, validation et contrôle des fichiers de paie générés par l'application APE Programme de l'iseor permettant de classer des phrases issues d'un diagnostic dans une nomenclature de dysfonctionnements Logiciel permettant de faire des simulations de salaire en fonction de différents éléments (commission paritaire, situation familiale,...) Logiciel utilisé par les RH dans le cadre du recrutement du personnel Logiciel de création, d'impression de codes-barres, Version du 17/11/2014 Page 5 sur 47 pages Dossier DMP /HTNMMN/EAI

6 étiquettes Autocad DWG Viewer Sketchup SQL Management Studio IDEA VLC Media Player Adobe Reader Adobe Acrobat Pro Adobe Creative Suite S6 Adobe Map Info Documentation/gestion contenu Confluence Jive Microsoft SharePoint Oracle Web Center Sites (Fatwire) WordPress Middleware Apache Web Server IIS Oracle WebLogic Oracle WebLogic Portal Monitoring BMC Performance Manager BMC TM-ART Enterprise manager Fortianalyser/manager GigaStore MS SCOM Network Observer What's Up Zabix Logiciel de CAO pour la DRM (lié à l application Archibus) Logiciel permettant de visualisé les dessins Autocad Logiciel de création d image 3D Logiciel pour effectuer des requêtes sur la base de données de l AMEF Logiciel de contrôle financier pour l Audit Interne et la Comptabilité Lecteur multimédia Lecteur de pdf Logiciel de gestion avancée de pdf Suite logicielle de création et diffusion de contenu media Logiciel de représentations géographiques et cartographiques de données Moteur Wiki, fourni par Altassian Forum internes Enterprise Content Management Web Content Server pour intranet et forem.be Gestion du contenu du journal interne du Forem Middleware - Server HTTP Serveur Web et Applicatif Microsoft Serveur d'application Oracle Portail oracle Capacity and performances analytics Transaction Management Application Response Time Outil d'administration pour Oracle DB, Solaris Solution de monitoring réseau firewall Monitoring spécifique du réseau Module de Service Center pour le monitoring des serveurs Windows Monitoring réseau Monitoring graphique synthétique du réseau Monitoring graphique synthétique du réseau Version du 17/11/2014 Page 6 sur 47 pages Dossier DMP /HTNMMN/EAI

7 Monitoring/Déploiement Cisco Prime (et works) IBM Director MS SCCM OS ios Microsoft Windows Microsoft Windows Server Oracle SUN Unix (Sparc) Réseau et sécurité Bluecoat Cisco Fortinet Juniper Service Management GetSMC MS SCSM Stockage IBM Tivoli Storage Librairie Overland Serveraid Manager (IBM) Solaris Volume Manager Virtualisation Citrix HyperV / SCVMM VMWare Oracle VM Solution de monitoring réseau de switch région et datacenter Monitoring hardware IBM Déploiement de patchs et packages sur postes et serveurs windows Système opératoire Apple Système opératoire postes clients Système opératoire pour les serveurs systèmes et applicatifs Système opératoire pour les serveurs applicatifs Solution hardware et software Proxy, Reverse Proxy et de webfiltering Solution hardware et software switchs, firewall interne, ladbalancing Solution firewall externe, webfiltering, antivirus Solution de VPN Accès à distance Application de gestion des incidents, changements et de l'asset Nouvelle Application de gestion des incidents, changements et de l'asset Logiciel de gestion de stockage d'entreprise Système de backup sur bande LTO Système de gestion RAID Système de gestion RAID Solution Citrix Xen App de virtualisation d'applications et logiciels Solution Microsoft pour la virtualisation de serveurs windows Solution pour la virtualisation de serveurs windows Solution pour la virtualisation de serveurs Unix Oracle Version du 17/11/2014 Page 7 sur 47 pages Dossier DMP /HTNMMN/EAI

8 3 Vue globale de l architecture des applications 3.1 Introduction Les développements du DSI s'orientent autour de deux axes : les applications les services (dans le sens SOA du terme) 3.2 Choix d'une architecture L'architecture standard (par défaut) est axée sur les Single-Page Applications et la création de services (SOA). Mais comme toujours, c'est à l'architecte de prendre les décisions architecturales dans le SAD (Software Architecture Document, analyse technique), en fonction des buts et des contraintes du projet, il peut s'orienter vers une architecture single-page, multipages ou une approche combinée. De manière générale, les applications single-page sont plus appropriées pour des applications de gestion et de CRUD. Les applications multipages sont quant à elles plus adaptées pour du contenu informationnel. 3.3 Architecture macro Le schéma suivant illustre l'architecture macro des applications single-page : 3.4 Description de l'architecture Une fois chargé, le front end de l'application réside dans le navigateur et est complètement autonome (pas de rechargement de pages). C'est lui qui est responsable de la couche Version du 17/11/2014 Page 8 sur 47 pages Dossier DMP /HTNMMN/EAI

9 présentation (GUI, MVC). Le front end considère le serveur non pas comme une source de pages (exception faite de la page de login) mais bien comme une source de données. La façade Web API gère l'authentification (actuellement avec une page de login, à l'avenir avec un token fourni par un STS), la logique business et les accès à la DB et aux services. Les services (SOA) identifiés dans le SAD (Software Architecture Document, analyse technique), doivent être implémentés dans un projet Web à part et faire l'objet d'un déploiement séparé. Les services doivent être tout à fait neutres par rapport au client. 3.5 Architecture des Web APIs et des services Le schéma suivant illustre un exemple d'architecture haut niveau des Web APIs et des services : 3.6 Description de l'architecture Cette architecture est basée sur deux principes : Le pattern REST La découpe Multi-Layer (Multi-Tier). Cette découpe permet une séparation claire des responsabilités : les problématiques de présentation, de logique business et d'accès aux données sont complètement dissociées les unes des autres. Chacune de ces problématiques est gérée par une couche dédiée (Presentation Layer, Business Logic Layer, Data Access Layer). Les éléments importants à retenir sont les suivants : Version du 17/11/2014 Page 9 sur 47 pages Dossier DMP /HTNMMN/EAI

10 Les contrôleurs ne font que valider les inputs du front end et retourner des représentations de ressources (XML / JSON). Les contrôleurs n'appliquent aucune logique business et n'accèdent jamais aux sources de données. Les domain models représentent des objets du domaine d'application (demandeur d'emploi, employeur, formation, dossier, adresse, prime, etc.). Les seuls objets échangés entre les contrôleurs et la couche Business Logic sont les Domain Models (ou des listes de Domain Models). La couche Business Logic est responsable de la logique métier (workflow, contrôle et application des règles business. etc.). Elle ne s'occupe jamais de problématiques de présentation ou d'accès aux sources de données. Les seuls objets échangés entre les couches Business Logic et Data Access sont les Domain Models (ou des listes de Domain Models). La couche Data Access est responsable de l'accès aux sources de données (base de données, service, etc.). Elle se charge des requêtes sur les données, des insertions de données, des modifications de données et des suppressions de données. Elle ne s'occupe jamais de problématiques de présentation et n'applique jamais aucune logique business. Elle ne retourne jamais d'objets intimement liés aux sources de données (ex : objets liés l'orm comme les entités Entity Framework, etc.). Elle renvoie des Domain Models. La couche Utilities est orthogonale aux autres couches et est en charge des problématiques communes (on parle de cross-cutting concerns). Elle contient des composants à but utilitaire, des helpers, etc. Pour qu'un composant ait sa place dans Utilities, il faut qu'il ne soit spécifique à aucune des autres couches (pas lié à la présentation, à la logique business ou aux accès aux données). Au contraire, il doit être pensé pour pouvoir rendre service à tout élément de l'application, peu importe la couche auquel ce dernier appartient. Par défaut, les contrôleurs ne peuvent pas accéder en direct à la couche Data Access sans passer par la couche Business Logic. Cependant, il arrive régulièrement que l'on veuille afficher/modifier des données sans qu'il faille appliquer la moindre règle business. Dans ce cas, il est permis aux contrôleurs de parler directement à la couche Data Access. 3.7 Architecture des applications multipages (architecture non-standard, sur décision de l'architecte uniquement) Le schéma suivant illustre l'architecture haut niveau des applications multipages : Version du 17/11/2014 Page 10 sur 47 pages Dossier DMP /HTNMMN/EAI

11 3.8 Description de l'architecture Cette architecture est basée sur deux principes : Le pattern Model View Controller La découpe Multi-Layer (Multi-Tier). Cette découpe permet une séparation claire des responsabilités : les problématiques de présentation, de logique business et d'accès aux données sont complètement dissociées les unes des autres. Chacune de ces problématiques est gérée par une couche dédiée (Presentation Layer, Business Logic Layer, Data Access Layer). Version du 17/11/2014 Page 11 sur 47 pages Dossier DMP /HTNMMN/EAI

12 Les éléments importants à retenir sont les suivants : Les vues (les pages Web) sont générées par les contrôleurs en y injectant des View Models. Ces View Models n'ont pas d'autre but que de servir cette logique de présentation. Les contrôleurs ne font que valider les inputs du front end et retourner des vues (contrôleurs Web) ou des représentations de ressources (XML / JSON) (contrôleurs API). Les contrôleurs n'appliquent aucune logique business et n'accèdent jamais aux sources de données. Les domain models représentent des objets du domaine d'application (demandeur d'emploi, employeur, formation, dossier, adresse, prime, etc.). Les seuls objets échangés entre les contrôleurs et la couche Business Logic sont les Domain Models (ou des listes de Domain Models). La couche Business Logic est responsable de la logique métier (workflow, contrôle et application des règles business. etc.). Elle ne s'occupe jamais de problématiques de présentation ou d'accès aux sources de données. Les seuls objets échangés entre les couches Business Logic et Data Access sont les Domain Models (ou des listes de Domain Models). La couche Data Access est responsable de l'accès aux sources de données (base de données, service, etc.). Elle se charge des requêtes sur les données, des insertions de données, des modifications de données et des suppression de données. Elle ne s'occupe jamais de problématiques de présentation et n'applique jamais aucune logique business. Elle ne retourne jamais d'objets intimement liés aux sources de données (ex : objets liés l'orm comme les entités Entity Framework, etc.). Elle renvoie des Domain Models. La couche Utilities est orthogonale aux autres couches et est en charge des problématiques communes (on parle de cross-cutting concerns). Elle contient des composants à but utilitaire, des helpers, etc. Pour qu'un composant ait sa place dans Utilities, il faut qu'il ne soit spécifique à aucune des autres couches (pas lié à la présentation, à la logique business ou aux accès aux données). Au contraire, il doit être pensé pour pouvoir rendre service à tout élément de l'application, peu importe la couche auquel ce dernier appartient. Par défaut, les contrôleurs ne peuvent pas accéder en direct à la couche Data Access sans passer par la couche Business Logic. Cependant, il arrive régulièrement que l'on veuille afficher/modifier des données sans qu'il faille appliquer la moindre règle business. Dans ce cas, il est permis aux contrôleurs de parler directement à la couche Data Access. 3.9 Architecture des applications devant a posteriori exposer des services Il arrive qu'une application doive a posteriori exposer des services. On procède alors comme indiqué dans le schéma suivant : Version du 17/11/2014 Page 12 sur 47 pages Dossier DMP /HTNMMN/EAI

13 Voici la marche à suivre : On crée un nouveau service qui partage les composants nécessaires de logique / data access avec l application initiale. Ce partage se fera par réutilisation de bibliothèques de classes (pas de double gestion de code). A cette occasion, il sera probablement nécessaire de restructurer légèrement l'application initiale afin d'extraire efficacement les composants à partager dans une dll. Ceci sera étudié au cas par cas et fera l'objet d'une décision de l'architecte. Attention à l'over-engineering! Si le SAD d'une application ne mentionne pas de service, il faut éviter de structurer l'application de manière à "facilement pouvoir en extraire un service quand ce sera nécessaire". Cet abus de prévoyance risque de compromettre la maintenabilité de l'application et nous préférons faire l'effort d'adaptation si cela s'avère nécessaire. Version du 17/11/2014 Page 13 sur 47 pages Dossier DMP /HTNMMN/EAI

14 Le service est bien sûr exposé sur l ESB. L'application initiale doit obligatoirement passer par le service pour accéder aux données sous le "contrôle" de ce dernier. Ce n'est pas parce que l'application à un accès direct à la DB qu'elle ne doit pas se conformer au SOA! Version du 17/11/2014 Page 14 sur 47 pages Dossier DMP /HTNMMN/EAI

15 4 Architecture ESB 4.1 Introduction L architecture d intégration est conçue autour de l ESB ServiceMix. Apache ServiceMix ( est un ESB Open Source combinant des fonctionnalités SOA et EDA (Event Driven Architecture). 4.2 Vue d ensemble Apache ServiceMix Service Backend CSM LDAP Apache ServiceMix Service Backend Application DB Client Apache ARCHITECTURE GÉNÉRALE DE L ESB INTERNE L architecture se compose des éléments suivants : Un «load balencer» (CSM - Cisco Content Switching Module) qui répartit la charge entre 2 serveurs Apache et détecte l'indisponibilité d'un serveur Apache. 2 serveurs Apache en façade des services de l'esb. Chaque serveur Apache façade une instance d'esb ServiceMix. Le rôle de ces serveurs Apache est de découpler les URLs publiques des services de l'esb des URLs "techniques" utilisées par l'esb. Les deux serveurs Apache sont Version du 17/11/2014 Page 15 sur 47 pages Dossier DMP /HTNMMN/EAI

16 aussi utilisés pour effectuer un Fail over rapide lorsqu'une instance de l'esb est indisponible mais que cette indisponibilité n'a pas encore été détectée par le CSM. 2 instances d'esb ServiceMix. 1 LDAP utilisé par les instances ServiceMix pour l'authentification et l'autorisation. Les instances de services backend. L'ESB se charge lui-même du load-balancing et du failover pour les appels vers les services backend (ces appels ne repassent donc pas par un CSM) ARCHITECTURE DE L'ESB EXTERNE Les échanges de données avec les partenaires externes se fait via d'autres instances de l'esb, situées dans un VLAN dédié de l'infrastructure. Derrière la séparation des ESB internes et externes, l'objectif est le suivant : contrôler l'api exposée aux partenaires externes : quels services, quelles méthodes, etc. avoir la possibilité de contrôler la charge venant de l'extérieur. Possibilité d'utiliser des mécanismes de throttling, protéger l'esb interne contre d'éventuelles attaques par DOS, avoir la possibilité de contrôler finement les données entrantes et sortantes ("application firewall"). 4.3 Mise en œuvre du SOA L ESB est le cœur de notre infrastructure SOA. Il façade l ensemble de nos services et procède à toutes sortes d orchestrations / transformations. Nos services se répartissent en deux grandes familles : Les services business o Référentiel entreprises o Nomenclature o Les services utilitaires : o Génération de documents o Archivage o Communication o Les services business exposent parfois (de façon propre) les données d une application legacy. Le schéma suivant fournit une vue haut niveau partielle de notre SOA : Version du 17/11/2014 Page 16 sur 47 pages Dossier DMP /HTNMMN/EAI

17 Version du 17/11/2014 Page 17 sur 47 pages Dossier DMP /HTNMMN/EAI

18 5 Standards de développements.net 5.1 Introduction Les développements.net sont la référence pour tout nouveau développement. Ce chapitre reprend les standards applicables aux développements.net réalisés pour le Forem. Les demandes de dérogation doivent être introduites à la Direction Architecture et figurer dans l'analyse technique (SAD). L'application des standards, et notamment les versions des librairies, doit être considérée dès la conception technique de l'application. En cours de développement, il est toujours préférable d'adapter le projet aux derniers standards disponibles, mais ce travail doit être évalué pour que les coûts, planning et qualité soit respectés. Si un développement n'adhère pas aux standards et n'a pas demandé, au préalable, une dérogation, il ne sera pas installé dans l'environnement de test (ACC). Si le manquement est constaté ultérieurement, il sera retiré de cet environnement, sans préavis ni communication préalable. Le responsable technique portera l'entière responsabilité de ce refus ou de ce retrait. Si le responsable sécurité ou l'architecture estime que les manquements sont graves, cette mesure pourrait s'étendre à l'environnement de production (PRD et Formation). 5.2 Technologies standards Technologie Standard Plateforme.NET Framework Langage C# ORM Entity Framework (Code First si possible) Framework Web ASP.NET MVC Services RESTful ASP.NET Web API Client HTTP Tests unitaires Microsoft Unit Test Framework Mocking Microsoft Fakes ou Moq IDE Visual Studio Application Lifecycle Management Team Foundation Server Source Control Git (TFS-Git) 5.3 Organisation INTÉGRATION CONTINUE Microsoft ASP.NET Web API Client Libraries Tous les projets de développement sont soumis à l intégration continue sur Team Foundation Server. A chaque commit, diverses mesures de qualités sont effectuées, le code est buildé, les tests unitaires sont exécutés et si tout est en ordre, la solution est déployée sur un serveur de développement GESTION DES SOURCES Les sources sont gérées uniquement par le serveur GIT (TFS-Git) mis à disposition par le DSI. Version du 17/11/2014 Page 18 sur 47 pages Dossier DMP /HTNMMN/EAI

19 Pour chaque "commit", un commentaire est obligatoire. Ne JAMAIS placer du code non testé ou non documenté VERSIONING Le versioning des applications et des bibliothèques de code développées au Forem doit suivre le schéma <x>.<y>.<z> où : x est le numéro de version majeure. Une version est majeure si une ou plusieurs des conditions suivantes sont rencontrées : o elle représente une évolution significative en termes de fonctionnalités o elle représente un changement dans la sémantique o elle induit des changements d'api cassant la rétro-compatibilité y est le numéro de version mineure. Une version est mineure si elle représente une évolution incrémentale en termes de fonctionnalités, sans changer la sémantique et sans casser la rétro-compatibilité. z est le numéro de patch. Une version est un patch si elle ne fait que corriger un ou des bugs, sans ajouter de fonctionnalités, sans changer la sémantique et sans casser la rétro-compatibilité. x, y et z sont bien entendu incrémentés de manière complètement indépendante. 5.4 Testing TESTS UNITAIRES Les tests unitaires sont obligatoires, pour toutes les classes. Ils doivent couvrir : toutes les méthodes publiques (à l'exception des accesseurs/mutateurs simples et des constructeurs vides) toutes les règles métiers tous les bugs corrigés Ils doivent de plus être : automatisés indépendants de l'environnement d'exécution. L'environnement de référence sera l'environnement de l'intégration Continue. Les composants ayant des dépendances externes devront être testés à l'aide de mocks. Enfin, les tests relatifs à une même classe devront être regroupés dans une même classe de test TESTS D INTÉGRATION Il faut distinguer deux types de tests d'intégration : Version du 17/11/2014 Page 19 sur 47 pages Dossier DMP /HTNMMN/EAI

20 Les tests d intégration de votre système : il s agit ici de tester l intégration avec des composants externes dont vous êtes responsables. Cela vaut aussi bien pour votre DB que pour les services que vous développez pour votre projet. Vous devez bel et bien réaliser des tests automatiques sur ces éléments et l intégration continue les exécutera également. Il faudra pour cela travailler sur des DBs/services en mémoire, etc. Les tests sur l ensemble de la chaîne : il s agit ici de tester l ensemble de la chaîne, et particulièrement les appels aux services de l ESB. Ceci ne peut se faire que dans l environnement d intégration et n est pas sujet à l intégration continue TEST D ACCEPTANCE Les scenarii de test sont rédigés par l'analyste. Avant d'effectuer une mise en ACC, ces scenarii devront être testés en DEV ou en INTEGRATION. Un rapport de test sera rédigé (Excel, au moins une ligne par scénario). Ces tests sont sous la responsabilité du responsable technique. 5.5 Version des frameworks / librairies (Mise à jour le 20/08/2014) Framework / librairie Version actuelle.net C# 5 Entity Framework 6.1 ASP.NET MVC 5.2 ASP.NET Web API 2.2 Automapper EPPlus Fakes.Contrib Log4Net Moq Ninject NLog Si une librairie n'est pas listée ici, elle est apriori interdite (Si une librairie "pirate" est découverte, elle sera supprimée, sans préavis ni communication préalable). Une librairie dépendante transitivement n'est pas à prendre en compte Les librairies utilisées pour les tests sont libres Version du 17/11/2014 Page 20 sur 47 pages Dossier DMP /HTNMMN/EAI

21 5.6 Guidelines CONVENTIONS DE NOMMAGE Nous utilisons les conventions de Microsoft ( avec quelques légers ajouts STRUCTURE DU CODE Ordre des membres Il est demandé de structurer le code de façon à ordonner les membres d'une certaine façon. Dans chaque classe, on retrouvera donc les membres dans l'ordre suivant : 1. Constantes 2. Attributs (champs d instance) 3. Constructeurs 4. Propriétés 5. Evénements 6. Méthodes Par "attribut", on entend le concept orienté objet désignant les données encapsulées (les champs d instance ou «champs privés»). A ne pas confondre avec le terme "attribute" utilisé dans la littérature.net pour désigner les décorateurs Utilisation de régions Afin d'améliorer la lisibilité du code, il est demandé au développeur d'utiliser des régions. Nommage des régions A noter qu'une région est définie de la façon suivante : #region Constantes #endregion Le nom de la région peut contenir n'importe quel caractère. Cependant, on ne l'entourera pas de guillemets. On écrira donc #region Constantes et non pas #region "Constantes" Modèle de régions standards #region Constantes #endregion Version du 17/11/2014 Page 21 sur 47 pages Dossier DMP /HTNMMN/EAI

22 #region Attributs #endregion #region Constructeurs #endregion #region Propriétés #endregion #region Méthodes #endregion Quand ne pas utiliser de régions? Les régions doivent être là pour améliorer la lisibilité du code. Si la lisibilité est suggestive, voici quelques cas où l'on ne devrait pas utiliser de régions. On ne doit pas définir de région vide (sans code à l'intérieur). o Le corollaire est que si vous utilisez le template défini ci-dessous, vous devrez supprimer toutes les régions dans lesquelles vous ne mettez pas de code Si une classe ne possède qu'un seul type de membre, il est préférable de ne pas les encadrer par une seule et unique région. o C'est typiquement le cas d'une exception custom qui ne définit que des constructeurs. Définir une région "Constructeurs" n'a que peu de sens Utilisation de sous-régions Il est tout à fait possible de définir des régions dans les régions standards définies ci-dessus. Ceci doit naturellement être utilisé avec parcimonie. Région standard "Méthodes" Si cela est pertinent en termes de lisibilité, il est possible de se passer de la région standard "Méthodes". Il est de plus conseillé de multiplier les régions au lieu d'avoir une seule et unique région "Méthodes" afin de clarifier la structure du code, et de regrouper les différentes méthodes d'un point de vue fonctionnel ou technique. Version du 17/11/2014 Page 22 sur 47 pages Dossier DMP /HTNMMN/EAI