DIMENSIONS à la STIME jeudi 20 mai 2010. PRÉSENTATION / 22/01/2014 2 Sommaire Historique...

DIMENSIONS à la STIME

jeudi 20 mai 2010

PRÉSENTATION / 04/11/23

2

SommaireHistorique

L’administration de DIMENSIONS

Le GSL

Les applications Mainframe• Organisation • Les rôles• Les requests• Les composants• Les projects• Le build

Les autres applications


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)


4

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

Administration de DIMENSIONS


5

Recette

Production

Developpement

Intégration

MDEV MCP

MREC_GSA

MREC_GSA

MREC_GSA

Mis en œuvre par la commande DEPLOY

Global Stage Lifecycle (GSL)


6

• 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

Les applications Mainframe : Organisation


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


8

Un seul cycle de vie porté par la request (DM)

Rejet possible à chaque étape

Avantages : • normalisé• souple d’utilisation• évolutif

Les applications Mainframe : Les requests

Annulée En_CoursMCP, MDEV

REC_GSA

En_Production

En_Recette

MCP, MDEV

REC_GSA

MCP, MDEV


9

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

Les applications Mainframe : Les requests


10

Les applications Mainframe : Les composants

• 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...)

GENERE

CP, DEV


11

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)

Les applications Mainframe : Projects (filières)


12

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



13

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.



14

Evolution

Check Out, Développement

Check In, Build Item

DEVELOPPEMENT

Build request

INTEGRATIONDeploy

RECETTE

deploy

Build request

Production

Filiè

re

PR

OD

Etudes

GEN DEV UT RELST

Recette Production

Filiè

re 0

0Fi

lière

0

1

RECETTE PRODUCTION

deploy

Co

pie

lo

ad

s

Copie loads



15

• 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


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


17


Annule Cree

Realise

Annulée InitialCP

DevCP_DEV

Pre-Recette

REC_GSA

Prod

CP

Pre-ProdTEST_FIRRecette

CP

Annulée InitialCP

DEVCP_DEV

Rec_Fonct

Prod

TEST_FONC

SDD

Creation PK

CP

Annulée packagingPACKAGING

Install_exploitTEST_FIR

Prod

PACKAGING

TEST_FIR

PACKAGING

SDDPrepa_Deploiement

SDD

SDD

PKDD

DMAD


18


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


19



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


20



Applications avec développement interne mais sans utilisation du plugin

• un seul type de request (DM) supportant les composants qui vont jusqu’en PROD


• Utilisation possible des baselines


21


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 d’utilisation de baselines


22

Questions ?

DIMENSIONS à la STIME jeudi 20 mai 2010. PRÉSENTATION / 22/01/2014 2 Sommaire Historique...

Documents

Transcript of DIMENSIONS à la STIME jeudi 20 mai 2010. PRÉSENTATION / 22/01/2014 2 Sommaire Historique...