1 / 22

DIMENSIONS à la STIME

DIMENSIONS à la STIME. jeudi 20 mai 2010. Sommaire. Historique L’administration de DIMENSIONS Le GSL Les applications Mainframe Organisation Les rôles Les requests Les composants Les projects Le build Les autres applications. historique.

beatrice
Download Presentation

DIMENSIONS à la STIME

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DIMENSIONS à la STIME • jeudi 20 mai 2010

  2. Sommaire • Historique • L’administration de DIMENSIONS • Le GSL • Les applications Mainframe • Organisation • Les rôles • Les requests • Les composants • Les projects • Le build • Les autres applications PRÉSENTATION / 04/06/2014

  3. 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 d’une 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 l’application maison GCPVCS) PRÉSENTATION / 04/06/2014

  4. Administration de DIMENSIONS Equipe de 3 personnes - Définir l’infrastructure d’accueil des applications - Réaliser les actions d’administration - Assurer le support technique - Assurer la formation des utilisateurs - Développer et maintenir les scripts autour de DIMENSIONS (deploy, rapports, etc…) 130 utilisateurs pour l’instant. - Lorsque toutes les applications seront définies  jusqu’à 500 personnes potentielles PRÉSENTATION / 04/06/2014

  5. Global Stage Lifecycle (GSL) Recette Developpement Intégration Production MDEV MCP MREC_GSA MREC_GSA MREC_GSA Mis en œuvre par la commande DEPLOY PRÉSENTATION / 04/06/2014

  6. Les applications Mainframe : Organisation • L’ensemble 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 d’une 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 d’un développement à la production d’un 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 à l’intérieur de la request PRÉSENTATION / 04/06/2014

  7. 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 PRÉSENTATION / 04/06/2014

  8. Les applications Mainframe : Les requests MCP, MDEV MCP, MDEV Annulée En_Cours MCP, MDEV REC_GSA En_Recette REC_GSA En_Production • Un seul cycle de vie porté par la request (DM) • Rejet possible à chaque étape • Avantages : • normalisé • souple d’utilisation • évolutif PRÉSENTATION / 04/06/2014

  9. Les applications Mainframe : Les requests • Pilotage du processus par la REQUEST • Build (Fabrication) de la totalité de la REQUEST (pas de build effectué si l’ITEM n’est pas modifié) sauf en développement • Pas de DEPLOY d’Items, 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 PRÉSENTATION / 04/06/2014

  10. Les applications Mainframe : Les composants CP, DEV GENERE • Ne possèdent pas de cycle de vie (cycle de vie mono état) • Ne possèdent pas d’attribut • 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 d’instructions participant au processus de fabrication (copy Cobol, include, load, complists...) PRÉSENTATION / 04/06/2014

  11. Les applications Mainframe : Projects (filières) • Organisation d’une 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) PRÉSENTATION / 04/06/2014

  12. Les applications Mainframe : Projects (filières) • 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 PRÉSENTATION / 04/06/2014

  13. Les applications Mainframe : Projects (filières) • 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 d’Item y sont automatiquement exportées. Un seul environnement de production pour toutes les filières. PRÉSENTATION / 04/06/2014

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

  15. Les applications Mainframe : Le Build • 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. PRÉSENTATION / 04/06/2014

  16. Les autres applications • Au départ : Utilisation d’un 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 d’un plugin • Développement interne ou externe • Un product par application non MVS •  Plusieurs types de requests PRÉSENTATION / 04/06/2014

  17. Les autres applications PACKAGING CP PACKAGING Annulée Initial Annulée packaging CP Dev PACKAGING CP_DEV TEST_FIR Annule Cree Pre-Recette Install_exploit SDD CP Recette TEST_FIR TEST_FIR SDD CP Pre-Prod Realise Prepa_Deploiement REC_GSA Prod Annulée Initial SDD CP Prod DEV CP_DEV Rec_Fonct TEST_FONC Creation PK SDD Prod AD DM PK DD PRÉSENTATION / 04/06/2014

  18. Les autres applications • Applications Centralisées • Applications Eclipse utilisant le plugin J2EE • Un type de request (DM) supportant les composants qui vont jusqu’en 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 PRÉSENTATION / 04/06/2014

  19. Les autres applications • Applications Centralisées • Applications provenant de l’extérieur • Un seul type de request (DM) supportant les composants qui vont jusqu’en PROD • Pas de build utilisé • Pas de baselines • DIMENSIONS n’est utilisé que comme référentiel de livraison à la production PRÉSENTATION / 04/06/2014

  20. 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 jusqu’en PROD • Pas de build utilisé • Utilisation possible des baselines PRÉSENTATION / 04/06/2014

  21. 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 jusqu’en PROD • Pas de build utilisé • Pas d’utilisation de baselines PRÉSENTATION / 04/06/2014

  22. Questions ? PRÉSENTATION / 04/06/2014

More Related