DIMENSIONS à la STIME

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