slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
DIMENSIONS à la STIME PowerPoint Presentation
Download Presentation
DIMENSIONS à la STIME

Loading in 2 Seconds...

play fullscreen
1 / 22

DIMENSIONS à la STIME - PowerPoint PPT Presentation


  • 121 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'DIMENSIONS à la STIME' - beatrice


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

DIMENSIONS à la STIME

  • jeudi 20 mai 2010
slide2

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

slide3

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

slide4

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

slide5

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

slide6

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

slide7

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

slide8

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

slide9

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

slide10

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

slide11

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

slide12

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

slide13

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

slide14

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

slide15

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

slide16

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

slide17

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

slide18

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

slide19

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

slide20

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

slide21

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

slide22

Questions ?

PRÉSENTATION / 04/06/2014