La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

DIMENSIONS à la STIME jeudi 20 mai 2010. PRÉSENTATION / 22/01/2014 2 Sommaire Historique Ladministration de DIMENSIONS Le GSL Les applications Mainframe.

Présentations similaires


Présentation au sujet: "DIMENSIONS à la STIME jeudi 20 mai 2010. PRÉSENTATION / 22/01/2014 2 Sommaire Historique Ladministration de DIMENSIONS Le GSL Les applications Mainframe."— Transcription de la présentation:

1 DIMENSIONS à la STIME jeudi 20 mai 2010

2 PRÉSENTATION / 22/01/ Sommaire Historique Ladministration de DIMENSIONS Le GSL Les applications Mainframe Organisation Les rôles Les requests Les composants Les projects Le build Les autres applications

3 PRÉSENTATION / 22/01/ historique 2004 : Constatation à la STIME des disparités en matière de logiciels de gestion de Configuration : ENDEVOR – GEPILIV – GERPAC pour le MVS PVCS(GCPVCS) – CVS – VSS pour les autres technologies Etude pour rechercher un outil unique de gestion de configuration Avril 2005 : Acquisition Dimensions version 9 Mai à Novembre 2005 : Paramétrage et déploiement des applications MVS (Deadline : arrêt de la license ENDEVOR fin novembre 2005) Octobre 2006 : Sortie de la version 10 de Dimensions Janvier 2007 : Déploiement dune première application non MVS Septembre 2007 : Installation de DIMENSIONS 10 sur le test, début de la customisation (utilisation du build SERENA au lieu du build OPENMAKE) Avril 2009 : basculement en DIMENSIONS 10 avec recompilation complète des composants MVS Avril 2010 : basculement des autres applications SO (utilisation du plugin DIMENSIONS dans Eclipse, basculement de lapplication maison GCPVCS)

4 PRÉSENTATION / 22/01/ Equipe de 3 personnes - Définir linfrastructure daccueil des applications - Réaliser les actions dadministration - Assurer le support technique - Assurer la formation des utilisateurs - Développer et maintenir les scripts autour de DIMENSIONS (deploy, rapports, etc…) 130 utilisateurs pour linstant. - Lorsque toutes les applications seront définies jusquà 500 personnes potentielles Administration de DIMENSIONS

5 PRÉSENTATION / 22/01/ RecetteProductionDeveloppementIntégration MDEV MCP MREC_GSA Mis en œuvre par la commande DEPLOY Global Stage Lifecycle (GSL)

6 PRÉSENTATION / 22/01/ Lensemble du SI concernant le mainframe dans un Product unique Une décomposition des Design Parts en Domaine / Secteur / Application Utilisateurs Etudes déclarés au niveau dune application Les autres utilisateurs (GSA, DBA) au niveau du product STIME (multi application) Les baselines ne sont pas utilisées Les requests représentent une livraison dun développement à la production dun ou plusieurs composants (programmes COBOL, copies, Maps, etc..). Le Build DIMENSIONS est utilisé. La mise au point est faite dans les PDS de chaque utilisateur Lors de la livraison en recette, les programmes sont systématiquement recompilés et les items dérivés (loads, listes de compilation) sont remontés dans DIMENSIONS à lintérieur de la request Les applications Mainframe : Organisation

7 PRÉSENTATION / 22/01/ Les applications Mainframe : Les rôles CP (Chef de projet) / DEV (Analyste-Programmeur) Rôle identique sur la phase Etudes Il sera possible de customiser si souhaitable DBA Délégué par les DEV ou le CP si il doit intervenir sur la request REC_GSA (Chargé de recette) pour la phase RECETTE Fait la recette en pre-prod et passe les requests en production

8 PRÉSENTATION / 22/01/ Un seul cycle de vie porté par la request (DM) Rejet possible à chaque étape Avantages : normalisé souple dutilisation évolutif Les applications Mainframe : Les requests AnnuléeEn_Cours MCP, MDEV REC_GSA En_Production En_Recette MCP, MDEV REC_GSA MCP, MDEV

9 PRÉSENTATION / 22/01/ Pilotage du processus par la REQUEST Build (Fabrication) de la totalité de la REQUEST (pas de build effectué si lITEM nest pas modifié) sauf en développement Pas de DEPLOY dItems, uniquement des DEPLOY de REQUESTS Les composants générés par les compilations (COMPLIST, LOAD, DBRMLIB) sont remontés systématiquement dans DIMENSIONS par la REQUEST Les applications Mainframe : Les requests

10 PRÉSENTATION / 22/01/ Les applications Mainframe : Les composants Ne possèdent pas de cycle de vie (cycle de vie mono état) Ne possèdent pas dattribut Leur format indique la façon dont ils vont être compilés (pour les composants buildables) Composants buildables nécessitent une compilation par lancement d'une chaîne de fabrication pour générer un programme exécutable Composant non buildables fichier dinstructions participant au processus de fabrication (copy Cobol, include, load, complists...) GENERE CP, DEV

11 PRÉSENTATION / 22/01/ Organisation dune filière Un project avec les composants en cours de modification Des Build Areas associés à un état du cycle de vie des composants Des PDS associés à chaque Build Area Des règles de fabrication configurées par Build Area (Search Paths pour utiliser les COPYs se trouvant dans les Build Areas supérieurs) Toutes les filières ont la même structure (Cycle de vie, Build Areas) Les applications Mainframe : Projects (filières)

12 PRÉSENTATION / 22/01/ Organisation GCL STIME Filière 00, 01, 02, 03, 04 : développement Filière Production Filière de référence Mises en production Correction urgente Les applications Mainframe : Projects (filières)

13 PRÉSENTATION / 22/01/ Règles Mise en production des Loads fabriqués et testés en Recette Seule la filière de production peut livrer des composants pour mise en production Mise à jour de la filière Production par les filières 00 à 04 La filière de production est utilisée pour les maintenances (request de type Correction ) Report des modifications dans les filières 00 à 04 Les filières de développement (00 à 04) sont utilisées pour les développements de type Evolution Toutes les filières sont au même niveau car à chaque mise en production, les révisions dItem y sont automatiquement exportées. Un seul environnement de production pour toutes les filières. Les applications Mainframe : Projects (filières)

14 PRÉSENTATION / 22/01/ Evolution Check Out, Développement Check In, Build Item DEVELOPPEMENT Build request INTEGRATION Deploy RECETTE deploy Build request Production Filière PROD Etudes GEN DEV UT REL ST RecetteProduction Filière 00 Filière 01 RECETTE PRODUCTION deploy Copie loads Les applications Mainframe : Projects (filières)

15 PRÉSENTATION / 22/01/ Build de la Request au lieu de builds Items, sauf dans la work area de chaque utilisateur Request obligatoire pour chaque Build car les items dérivés (Load, complist, DBRM) sont remontés dans DIMENSIONS pour les références croisées. Cas particulier de PACBASE : PACBASE génère le programme COBOL qui est envoyé dans DIMENSIONS et compilé automatiquement Bien que le Build se fasse au niveau de la Request, seules les sources ayant besoin dêtre construites seront recompilées. Les applications Mainframe : Le Build

16 PRÉSENTATION / 22/01/ Les autres applications Au départ : Utilisation dun seul product pour tout le SI STIME avec un seul type de request (DM). Mais manque de souplesse devant des technologies et des besoins différents Applications centralisées Applications non centralisées (dans les magasins) Utilisation dun plugin Développement interne ou externe Un product par application non MVS Plusieurs types de requests

17 PRÉSENTATION / 22/01/ Les autres applications AnnuleCree Realise AnnuléeInitial CP Dev CP_DEV Pre-Recette REC_GSA Prod CP Pre-Prod TEST_FIR Recette CP AnnuléeInitial CP DEV CP_DEV Rec_Fonct Prod TEST_FONC SDD Creation PK CP Annuléepackaging PACKAGING Install_exploit TEST_FIR Prod PACKAGING TEST_FIR PACKAGING SDD Prepa_Deploiement SDD PK DD DM AD

18 PRÉSENTATION / 22/01/ Les autres applications Applications Centralisées Applications Eclipse utilisant le plugin J2EE Un type de request (DM) supportant les composants qui vont jusquen PROD Un type de request (AD) pour la partie développement utilisant les composants générés par Eclipse. Build des items à partir de baselines pour constituer un.ear remonté dans DIMENSIONS dans une DM

19 PRÉSENTATION / 22/01/ Les autres applications Applications Centralisées Applications provenant de lextérieur Un seul type de request (DM) supportant les composants qui vont jusquen PROD Pas de build utilisé Pas de baselines DIMENSIONS nest utilisé que comme référentiel de livraison à la production

20 PRÉSENTATION / 22/01/ Les autres applications Applications Centralisées Applications avec développement interne mais sans utilisation du plugin un seul type de request (DM) supportant les composants qui vont jusquen PROD Pas de build utilisé Utilisation possible des baselines

21 PRÉSENTATION / 22/01/ Les autres applications Applications Décentralisées Applications avec ou sans développement interne Deux types de request (DD et PK) supportant les composants qui vont jusquen PROD Pas de build utilisé Pas dutilisation de baselines

22 PRÉSENTATION / 22/01/ Questions ?


Télécharger ppt "DIMENSIONS à la STIME jeudi 20 mai 2010. PRÉSENTATION / 22/01/2014 2 Sommaire Historique Ladministration de DIMENSIONS Le GSL Les applications Mainframe."

Présentations similaires


Annonces Google