SERENA RELEASE MANAGEMENT

Transcription

1 serena.com SERENA RELEASE MANAGEMENT

2 TABLE DES MATIERES 1 INTRODUCTION COMPREHENSION DES ENJEUX RELEASE CONTROL : DESCRIPTION ET AVANTAGES SCHEMA DE LA DYNAMIQUE DU MODULE RELEASE CONTROL PRINCIPALES FONCTIONNALITES DE LA SOLUTION RELEASE CONTROL RELEASE VAULT : DESCRIPTION ET AVANTAGES SCHEMA DE LA DYNAMIQUE GENERALE DU MODULE RELEASE VAULT PRINCIPALES FONCTIONNALITES DU MODULE SERENA RELEASE VAULT Gestion du patrimoine applicatif (référentiel des sources et applications) Gestion de la qualité du référentiel Gestion des environnements RELEASE AUTOMATION : DESCRIPTION ET AVANTAGES SERENA RELEASE AUTOMATION FONCTIONNALITES DE LA SOLUTION RELEASE AUTOMATION Solution Release Automation La solution Release Automation est centrée sur la notion d application et d architecture applicative Bibliothèque d actions Processus Abstraction des variables Association Processus/Environnements Traçabilité CONCLUSION : Page 2 of 22

3 1 Introduction Acteur majeur dans le domaine de l ALM (Application Lifecycle Management), Serena Software fournit des solutions permettant d optimiser la mise en service des applications de l entreprise. La clé de son succès réside dans sa capacité à gérer les demandes (Demand Management), le développement (Development Management) et la mise en production (Release Management) qui sont traitées comme un processus métier contrôlé de bout en bout. Vélocité et efficacité dans un monde piloté par les applications Nous vivons dans un monde où les applications informatiques ont définitivement intégré notre quotidien. Les banques et assurances délivrent plus de services à leurs clients via les portails internet et les automates que par les employés aux guichets. Les différentes administrations gouvernementales proposent de simplifier toutes nos démarches allant de la déclaration de revenus jusqu à la demande du moindre document officiel via de nouveaux sites internet. Les compagnies aériennes vendent leurs billets, promeuvent leurs programmes de fidélisation, vous laissent choisir votre place et vous enregistrer directement depuis votre PC ou des bornes automatiques. Jusqu à nos voitures où le code logiciel se compte maintenant en millions de lignes de code. Et ce ne sont là que des exemples à destination des particuliers. Les relations entre entreprises sont depuis longtemps gouvernées par des applications, depuis la logistique jusqu à la relation client, depuis la fabrication jusqu à la gestion. Assurer l exploitation au quotidien de ces applications n a jamais été aussi peu cher grâce à la virtualisation, au «cloud» et à la baisse continue du rapport prix/puissance des infrastructures. Le véritable enjeu est de pouvoir livrer en production efficacement et avec un délai le plus court possible entre la manifestation de la demande par les opérationnels (le business) et le déploiement de l application. Un enjeu qui relève du défi car avec un parc applicatif aussi important à maintenir, le budget pour l innovation (les nouvelles applications) n a jamais été aussi réduit. L utilisation de ressources en sous-traitance ou en offshore atteint ses limites. Cette solution peut même devenir contre-productive sans la mise en place d un processus adéquat qui orchestre les activités de bout en bout. Les véritables sources de productivité sont dans l amélioration de l efficacité tout au long du cycle de vie. Il faut mettre fin à l effet «silo» qui amène chaque équipe tout au long de ce cycle de vie à focaliser ses actions de progrès sur son métier spécifique tout en ignorant radicalement comment recevoir et passer les informations pertinentes à l équipe suivante. «L utilisation de moyens manuels (voire papier) pour assurer la gestion de l échange d information entre les différentes étapes du cycle de vie applicatif est en train d évoluer vers plus d automatisation et vers des processus interconnectés.» - Jim Duggan, Gartner Group Page 3 of 22

4 Les solutions de Serena sont orchestrées par Serena Orchestrator, un «bus de communicationn et d automatisationn». Conçu selon unee architecture ouvertee et autour d un puissant moteur de workflow,, ce module central dans l offree de Serena permet de construire le processus de bout en bout et d intégrer les meilleurs outils du marché. Il inclut notamment des outils choisis par voss équipes en fonction de leurs besoins particuliers. Ces outils sont fournis par Serena, d autress acteurs du marché et par des initiatives Open Source. La solution de gestion du déploiement et de mise en production de Serena La solution de gestion du déploiement et de mise en productionn de Serena couvre trois disciplines de gestion qui peuvent êtree traitéess séparément ou concomitamment : Contrôle du déploiement (Release Control) : il permet de gérer de bout en bout le processus de déploiement, de garantir l application des politiques en matière de livraison et les droits des différentss acteurs tout au long du processus. Les activités de pré-déploiement et de déploiement sont planifiées, validées, orchestrées et tracées. Coffre-fort des livrables (Releasee Vault) : la synchronisation duu travail de plusieurss équipes nécessite de pouvoir identifier à un moment l ensemble des livraisons de Page 4 of 22

5 chacune de ces équipes. Ces livraisons doivent ensuite être organisées logiquement et en cohérence en fonction des objectifs de chaque type de livraison vers l étape suivante du cycle de vie (recette utilisateurs, pré-production, production, etc.). Nous recommandons d organiser cette gestion formelle au a sein d un référentiel. Les différents chemins possibles vers la production sont identifiés en fonction des typologies d applications, des architectures et de la nature des changements et du format des packages de livraison. (Ce référentiel de livraison, le coffre-fort, constitue la mémoire du SI en matière d auditabilité et garantitt la dynamique des mises en production.) Automatisation des livraisons (Releasee Automation) : ellee consiste en une simplification, industrialisation et abstraction des scripts de misee en production pour coordonner les différentes étapes et travaux à réaliser tout t au long du cycle de vie en fonction des architectures et des pré-requis d installation des différents packages de livraison (vérification des conditions d installation, arrêt et redémarrage d éléments d infrastructure, etc.). 2 Compréhension dess enjeux Au-delà de la gestion du cycle dess développements applicatifs, a la capacité à définir et industrialiser la mise en service des applications est un enjeuu majeur identifié par les entreprises. En mettant en place un référentiel des processus d installation qui définit les comportements typiques (en matière de déploiement) de toutes t les applications, qui s appuie sur un langage déclaratif pour définir ces comportements ainsi que les valeurs et variables, les entreprises souhaitent se donner les moyens d industrialiserr et d automatiser ces processus pour les différentes filières f de développement. Cette normalisati ion permet d accroître la souplesse relative à la gestion de ces filières de développement (communautés interness de développement, sous-traitance, Near-Shore, Off-Shore ou acquisition de solutions packagées). Elle permet de standardiser les l processus de déploiement et de consolider la cohérence e Page 5 of 22

6 et la fiabilité applications. des installations tout en réduisant les temps d indisponibilité des Cet enjeu est d autant plus important que cette gestionn du déploiement applicatif est encore aujourd hui une «zone grise» peu définie par p des normes ou standardss reconnus. En effet, il est essentiel pour les utilisateurs de disposer de la dernière version d une application au moment où ils en ont besoin. Il s agit pour eux d un «service». Les recommandations ITIL peuvent s appliquer dans ce contexte. La a prise en compte de la qualité des applications est un processus quee toute organisation devrait constamment améliorer. Les bonnes pratiques et recommandations CMMI peuvent être appliquées pour y parvenir. Cependant, la gestionn d une DSL (Definitee Software Library) est insuffisante pour prendre en compte la complexité des processuss modernes de développement et CMMI n aborde pas la notion de gestion des niveaux de service (SLA). De plus, les spécificitéss liées à la gestionn des plates-formess successives et à l industrialisationn des processus de livraisons (assemblages dans les différents environnements et variabilisation/abstraction de laa matière afin de la rendre indépendante des plates-formes technologiquess et des architectures) ne sont pas prises en compte. En conséquence, dans la trèss grande majorité des cas un processus ad hoc et majoritairement manuel a été mis en place. Les enjeux relatifs à la fiabilité duu système d information sont cruciaux, comme le montre le graphe suivant. Il synthétise l opinion de deux grands analystes du marché vis à vis de cette discipline : Page 6 of 22

7 60% de tous les arrêts d applications en production sont liés à des problèmes de configuration et de déploiement.(idc survey 2009) Plus de 75% du temps des équipes est passé à gérer les applications et leur déploiement. (Forrester, 2009) La solution de gestion des releases et du déploiement de Serena traite ces problématiques et s appuie sur des mises en œuvre concrètes dans des environnements clients. Elle constitue une solution qui permet d édifier un pont entre le développement et la production afin d accroître la collaboration entre ces deux acteurs majeurs du système d information. La notion de cycle de vie est présente à tous les niveaux de la solution Serena Release Management. Le point fort de la solution est la mise en place de workflows par typologie d objet. Chacun de ces workflows permet de traiter les activités propres à un objet et de garder ce workflow aussi simple que possible. Par exemple, le workflow d un objet donné peut ne comporter que deux états : «en cours de traitement» et «validé» ou des appellations similaires appropriées à l activité. Les workflows étant indépendants, le processus peut évoluer plus facilement : des étapes peuvent être ajoutées, modifiées ou supprimées aux différents niveaux sans remettre en cause l ensemble, et des règles de cohérences peuvent être établies (par exemple, pas d élément «en cours de traitement» au-delà de l environnement d assemblage). Enfin, les modules Serena Release Control et Serena Release Vault permettent d assurer la séparation des workflows purement organisationnels qui sont gérés par Serena Release Control, des workflows purement techniques gérés par Serena Release Vault. Page 7 of 22

8 Serena Release Control s appuie sur le produit Serena Business Manager qui va permettre d orchestrer les activités du niveau technique depuis le l niveau organisationnel, selon le schéma suivant : Page 8 of 22

9 3 Release control : description et avantages 3.1 Schéma de la dynamique du module Serena Release Control 1 Le calendrier des releases estt créé. On y définit les trains de releases (paliers) en spécifiant les dates, les étapes, les durées. Il est possible d ajouter à tout moment une release dans le calendrier (unee livraison urgente, par p exemple). Page 9 of 22

10 2 Une fois le calendrier établi, laa composition des releases s effectue en ajoutantt des releases d applications (une ou plusieurss dans le cas c d un palier). Il est possible à tout moment d ajouter ou de retirer une application qui participee à une release. Les liens de dépendances établis dans le coffre-fort (Release Vault) peuvent être sollicités lors de ces opérationss pour spécifier la participation ou non d une application et ses dépendances ou pour vérifier l éventuelle suppression d une application (dans ce cas,, elle ne peut pas être le pré-requis d unee autre). 3 Pour chaque application participant à une release, un ou plusieurs conteneurs destinés à recevoir les «deploy units» peuvent être construits c (les deploy units ou unités de déploiement sont issues des assemblages réalisés au sein du coffre-fort). 4 Pour chaque conteneur, les «deploy units» peuvent être sélectionnées lors de la navigation dans le catalogue du coffre-fort. Outre le déploiement sur l environnement prévu par p l étapee du cycle de vie concernée, il est alors possible de piloter les tâches dee déploiement. La traçabilité et la gestion des droits sontt gérées dee bout en bout. 3.2 Principales fonctionnalités de la solution Serena Release Control Serena Release Control permet dee définir les processus de contrôle dee haut niveau des releases dont less composants sont gérés par lee coffre-fort et sont identifiés commee des releases packages. Selon laa clé d extraction utilisée, un releasee package fera référence à unee baseline ou à une demande. Serena Release Control permet dee définir et de structurer les releasess selon leur nature : release majeuree (Main Release), mineure (Minor Release) ou à caractère d urgencee (Emergency Release). Cettee structuration permet de prendre en compte les «paliers» ou trains de releasess que l on traitera comme des releases majeures, les «hors paliers» que l on traiteraa comme des releases mineures et les «maintenancee à chaudd» que l on traiteraa comme des releases à caractère d urgence. Des processuss de validation de mise en service indépendants des workflows propres aux composants peuvent être associés à chacune de ces c releases. Cette capacité à traiter les workflows «organisationnels» et «techniques» de manière séparée contribue à une plus grande flexibilité de la solution et e renforcee son adaptation au changement. Page 10 of 22

11 4 Release Vault : description et avantages 4.1 Schéma de la dynamique générale du module Serena Release Vault Développements externalisés Développements internes Page 11 of 22

12 1 Les composants intégrés au coffre-fort (Release Vault) sont préalablement vérifiés (règle de nommage, qualité de code, variabilisation, etc...). (Jaune) Dans le cas de la filière «Usines de développement», il est possible que seuls les invariants soient livrés avec les fichiers paramétrables associés. Nous recommandons de mettre en place au niveau du SAS de livraison une procédure de «clean build» s appuyant par exemple sur un serveur d intégration continue qui pourra en outre être utilisé pour assister (Lot 3) à la mise en place d une interface bidirectionnelle avec les usines. (Vert) Dans le cas de la filière «Mainframe et Delphi», les fichiers sources sont livrés avec les fichiers paramétrables et chargés dans le référentiel. Ils seront refabriqués d environnement en environnement selon les circuits. 2 (Jaune) Clean Build pour produire les invariants (binaires : EAR, etc.) côté monde distribué. 3 Les composants (invariants ou sources et fichiers paramétrables) sont chargés dans le référentiel selon le modèle qui en aura été établi. Ils sont groupés et identifiés lors de cette opération. Chaque lot de livraison pourra ainsi être manipulé comme un tout. (Rose) Les paramètres sont eux aussi gérés à cette étape, soit directement dans la livraison via le bon de livraison qui peut détailler pour chaque environnement les paramètres techniques et fonctionnels, soit dans le référentiel par le «métier» pour les paramètres fonctionnels (et potentiellement via l équipe projet ou une MOA déléguée) ou par les exploitants pour les paramètres techniques (il est aussi possible que ces paramètres techniques soient obtenus par interrogation de la CMDB). 4 Une fois ces composants applicatifs identifiés et stockés au sein du référentiel, ils sont disponibles pour «rejoindre» les releases qui ont été établies. 5 Dans la plupart des cas, ils seront, pour ce faire, constitués en assemblages (regroupement de lots de livraison) puis en package de livraison. Selon la filière, il y aura (Vert) ou pas (Jaune) de refabrication (dans ce dernier cas, la fabrication s arrête au niveau de la pré-production). Pour le passage en production, on fait une copie des binaires exécutables. 6 Les packages de livraison peuvent alors être installés sur les serveurs et, en fonction des codes retour, la CMDB renseignée. 7 A la validation sur l environnement courant (contrôlé par le module Serena Release Control), les opérations 5 et 6 peuvent être répétées pour l environnement suivant. 4.2 Principales fonctionnalités du module Serena Release Vault Gestion du patrimoine applicatif (référentiel des sources et applications) Serena Release Vault s appuie sur son référentiel pour gérer les configurations. Ce référentiel est hébergé par une base de données relationnelle (Oracle ou SQL Server) et un système de stockage (file system) de tous les artefacts pouvant être installés sur le système d information. Page 12 of 22

13 Les configurations, leurs composants et leurs versions successives sont stockéss dans ce référentiel. Les informations relatives à leurs évolutionss sont disponibles à tout moment. Tous les types t d objets, codes source, binaires, documents, modèles sont supportéss par le modèle objett de Serena Release Vault. Pour chaque configuration et composant, Serena Release Vaultt stocke les attributs qui caractérisent ces objets et l historique de tous les événementss qui les ont affectés ainsi que leurs relations. Serena Release Vault fournit les commandes permettant d ajouter, de consulter, de supprimer (logiquement)) des composants. Des outils d interrogation s appuyant sur les attributs ou les relations caractérisant les composants offrent des fonctions de recherche au sein de ce référentiel et permettent l affichage et la navigation suivant les dépendances. Avec Serena Release Vault, vouss pouvez décrire l organisation de votre système d information en le déclinant comme suit : Système, Applications, Sous-systèmes, que votre organisation le nécessite. Serena Release Vault supporte la notion de réutilisation, ce qui signifie qu un sous-système ou module peut être partagé entre différentes applications ou systèmes. Serena Release Vault gère vos configurations pour tous ces niveaux (Système, Modules, etc. Vous pouvez gérer autant de niveau de décomposition Application, Sous-système, Module, etc.). Des configurations de bas niveaux peuvent être fusionnées pour gérerr des configurations de niveau supérieur. Page 13 of 22

14 4.2.2 Gestion de la qualité du référentiel Serena Release Vault garantit la qualité du référentiel par la définition de règles de chargement (appelées «Upload Rules») qui vont assurer le lien entre un type d élément au sein du référentiel et un fichier proposé au chargement dans le référentiel. Ces règles de chargement sont un pré-requis à toute prise en compte de composants au sein de Serena Dimensions CM. De nombreuses règles par défaut sont fournies avec l outil. Ces règles permettent de définir des modèles (ou patterns) de noms de fichiers et de les rapprocher des types de composants définis dans Dimensions CM. Ces règles peuvent être générales pour Serena Release Vault, spécifiques à un type d interface avec un EDI donné ou spécifiques à un projet particulier géré par Dimensions CM. Les règles générales (fournies avec l outil et disponibles dès l installation) décrivent 77 patterns permettant d identifier automatiquement des types de composants. Á ces 77 types génériques viennent s ajouter des patterns prédéfinis pour 22 EDI 1 du marché (il s agit d EDI certifiés par Serena, d autres EDI supportés par leurs éditeurs peuvent être ajoutés). Pour chacun de ces EDI, les types appropriés permettant d identifier automatiquement les composants ont été ajoutés. De plus, au chargement dans le coffre-fort, il est possible d utiliser tout type d outil de contrôle de qualité de code (à condition que celui-ci soit accessible par le biais d un mode Ligne de commande). Le résultat de l analyse peut être chargé dans le référentiel ou peut déclencher une action de rejet du chargement du «lot» dans le référentiel de Dimensions CM. Le chargement dans le référentiel s effectue en renseignant des attributs des éléments analysés ou en renseignant des attributs d un objet de regroupement tel que la baseline ou la demande avec les résultats de ces analyses Gestion des environnements La notion d environnement est multiple dans le coffre-fort. Elle permet effectivement de supporter les activités de déploiement des applications, de gérer les variables et paramètres spécifiques à chaque environnement et d assurer leur valorisation lors des déploiements. Des variables spécifiées à différents niveaux (Artefact, Type d artefact, Composant logiciel, Environnement) peuvent être gérées sous forme d attributs. Á chaque version de composant est associée la définition des différents paramètres fonctionnels (ou techniques) qui devront être valorisés lors du déploiement. Serena Release Vault gère des éléments dont les attributs sont valorisés lors de la mise à disposition dans un environnement. Les valeurs des attributs sont gérées par version de l élément. 1 EDI : Échange de Données Informatisé Page 14 of 22

15 Ex : Format du fichier de configuration incluant les paramètres du serveurr oracle. Serena Release R Vault permet de gérerr les valeurs dee ces variables (%MACHINE%, %INSTANCE%, %SYS_USER%, %SYS_PWD% et d autres si nécessaire) via des attributs. Serena Release Vault permet d associer à chaque environnement de déploiement correspondant à une phase du cycle de vie applicatif des procédures propres à chaque projet déployé. HELLO_DEPLOY_QUALIF est e un environnement de qualification du projet Suite_Rel_6 Des scripts spécifiques à cet environnement de déploiement seront exécutés en pré, post ou en cas d erreurs. Lors d un déploiement sur cet environnement, Serena Release Vault exécute le script «pre-event» avant de déposer les fichiers sur l environnement cible, le script «post-event» après le dépôt de fichier et le script «fail-event» en cas d erreur lors du déploiement. Page 15 of 22

16 Exemple : Déploiementt de la release 5.1 : (configuration FULL_RELEASE 51) Déploiement de la configuration FULL_RELEASE_51 Le système est capable de ne déployer que les composants qui ont étéé modifiés entre l état actuel de l environnement cible et la version à déployer. Avec Serena Release Vault, le déploiement s effectue de d façon intelligente grâce aux métadonnées déposéess lors dess déploiements précédents. Seuls les éléments nécessaires sont déployés. Ainsi, les fichiers déjà présents et non impactés ne sont pas redéposés. Les fichiers déployés peuvent êtree compressés pour alléger a la volumétrie transférée via le réseau. Serena Release Vault vous permet de naviguer et de parcourir directement les environnements de déploiements depuis les clients (windows ou web). Des icônes et des attributs signalent l état duu fichier déposé sur le système de stockage relativement au référentiel (fichier inchangé, modifié ou nouveau) ). 5 Release Automation : description et avantages 5.1 Serena Release Automation La solution Serena Release Automation s appuie sur le produit t NOLIO ASAP pour lequel Serena a obtenu une licencee de distribution de type OEM et de rebranding. Dans la perspective générale de laa solution, de NOLIO ASAP intervient lorsquee : l exécution des automates d installation 1) Les ensembles de composants constituant les releases ont été sélectionnés. Cette opération peut être effectuée via la solution Serena Release Control en parcourant les listes l d ensembles de composants référencés dans le référentiel de la solution Serena Release Vault. Cependant, toute solution de mise à disposition dans unee arborescence bien constituéee des composants à Page 16 of 22

17 déployer est suffisante pour la mise en œuvre indépendante de la solution Serena Release Automation. 2) Les releases ont été planifiées et approuvées pour chacune des étapes du cycle de vie (et à minima la prochaine étape). Ces opérations peuvent être effectuées via la solution Serena Release Control. Cependant toute solution de planification est suffisante pour la mise en œuvre indépendante de la solution Serena Release Automation. 3) Les composants et les fichiers de paramètres valorisés ont été transportés sur les serveurs cibles finaux. Cette opération est réalisée par la solution Serena Release Automation. La solution Serena Release Automation permet alors d exécuter les automates de mise en service des applications. 5.2 Fonctionnalités de la solution Serena Release Automation Solution Serena Release Automation Gestion de la «variabilisation» avec un plus haut niveau d abstraction. Maintenance de nombreux scripts (automates) complexes, en particulier lorsque les «ends points» deviennent très nombreux. Construction des enchaînements de scripts complexes nécessitant de faire coopérer des acteurs d expertises complémentaires. Exécution des scripts en synchronisant des activités entre plusieurs serveurs. Production d un reporting unifié des activités de déploiement au niveau des environnements physiques La solution Serena Release Automation est centrée sur la notion d application et d architecture applicative Les automates (appelés Process dans l outil) sont constitués en fonction de l architecture applicative. L outil articule l ensemble des processus autour de plusieurs «conteneurs» dont le plus générique est l application. Chacun de ces conteneurs sera utilisé/mis en relation avec une subdivision du référentiel applicatif défini par la solution Serena Release Vault et porté par le concept de Design Part (un conteneur Application de Nolio), tout comme un Build Project peut être mis en relation avec plusieurs Design Part. Toutes les applications correspondant à la même architecture applicative peuvent utiliser les automates d un conteneur applicatif Nolio. Page 17 of 22

18 Au sein de chaque «conteneur d applications», des composants applicatifs constitutifs de l application (ou des applications) vont être définis ainsi que les «actions» qui peuvent être réalisées sur ces composants applicatifs. Un serveurr d application (Tomcat ou Websphere) va, par exemple, constituer un composant de l architecture applicative et l arrêt du serveur d application est unee «action» qui peut être réalisée sur ce composant. Des ensembles cohérents d enchaînements d actions peuvent être définis (sorte de «macro») et constituentc t alors des «flows». L arrêt/relancee d un serveur d application, par exemple, est un «flow» Bibliothèque d actions La solution est fournie avec unn grand nombre d actions disponibless pour de nombreuses technologies. De nouvelles actions sont livrées régulièrement. Les actions sont livrées au format.jar et sont facilement intégrables dans une installation. Elles sont indépendantes de l infrastructure de la solution. Plus de 700 actions disponibles Manipulation graphique permettant les développements non spécialistes Variables intégrées directement valorisables complexes par des Page 18 of 22

19 Les problématiques de scripting complexes sont gérées via unn langage qui permet de disposer d un nouveau niveau d abstraction. graphique Riche bibliothèque d actionss pré-câblées pour tous types de technologies Stockage Base de données Serveur d application etc. Editeur de flux graphique Ajout d action par glisser-déposer Paramétrage (utilisation des fichiers de paramètres Dimensionss CM ) déposés par Autant de tiers que nécessaire dans une orchestration Processus La solution permet de construire des processus qui q prennent en compte les différentes architectures applicatives (mono ou multi-tiers). Les automates peuvent être définis par glisser-déposer des actions. Ces automates similaires à des automates d états permettront d enchaîner les actions ou les «flows» pour construire les processus d installation des composantss applicatifs. Le déploiement multi-tiers est orchestré : L enchaînement des opérations par serveur est construit c graphiquement Les dépendances identifiéess et les codes retourss attenduss Page 19 of 22

20 Les reprises sur erreurs sont gérées Abstraction des variables La solution Serena Release Automation permet d introduire un nouveau niveau d abstraction des variables. Certaines variables locales (dépendantes du serveurr cible final) pourront notamment être valorisées à laa «dernière minute» lors de l exécution du processuss sur le serveur. Ces variables sont valorisables parr niveau de structuration selon différents modes : Valeur directe Valeur indirecte (à partir d une autre variable) Valeur calculée (y compris par exécution de requête) r Par saisie lors de l exécution du processuss (mot dee passe que l on ne souhaite pas stocker parr exemple) Stockage en clair ou crypté Page 20 of 22

21 5.2.6 Association Processus/Environnementss Avant l exécution d un processus, une association est définie d entre le modèle logique abstrait au niveau de l architecture et les serveurs physiques sur lesquels le processus sera exécuté. Les dépendances entre serveurs dee nature différentes doivent être indiquées. Ainsi, pourr un déploiement surr 50 serveurs d application et 3 serveurs de bases de données, on pourra par exemple indiquer que les serveurss d applications 1 à 20 sont dépendants du serveur de base de données 1, les serveurs d applications 21 à 30 sont dépendants du serveur de base de données 2 et enfinn les serveurs d applications 31 à 50 sont dépendants du serveur de base de données 3. Page 21 of 22

22 5.2.7 Traçabilité L ensemble des résultats d exécution de chacune des actions sur chacun des serveurs est tracé et stocké dans la base de donnéess relationnelle de la solution et permet ensuitee d exécuter tout type de rapport ou recherche. r Ces données sont disponibles et accessibles pour alimenter les tableaux de bord enn fonction des profils utilisateurs. 6 Conclusion : Suite à l augmentation du nombre de releases, leur fréquence et leur complexité, le processus de déploiement devient un goulot d étranglement et unn risque majeur pour la qualité globale du système d information. Il est e nécessaire de s efforcerr d industrialiserr ce processus pour redynamiser la gestion complète du cycle de vie depuis le développement jusqu à la production. C est ce c défi quee la solution Serena Release Management permet de relever. Page 22 of 22