Upload
leonie-lecoq
View
108
Download
0
Embed Size (px)
Citation preview
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
PRÉSENTATION / 04/11/23
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/11/23
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
PRÉSENTATION / 04/11/23
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)
PRÉSENTATION / 04/11/23
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
PRÉSENTATION / 04/11/23
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/11/23
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
PRÉSENTATION / 04/11/23
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
PRÉSENTATION / 04/11/23
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
PRÉSENTATION / 04/11/23
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)
PRÉSENTATION / 04/11/23
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
Les applications Mainframe : Projects (filières)
PRÉSENTATION / 04/11/23
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.
Les applications Mainframe : Projects (filières)
PRÉSENTATION / 04/11/23
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
Les applications Mainframe : Projects (filières)
PRÉSENTATION / 04/11/23
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
PRÉSENTATION / 04/11/23
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/11/23
17
Les autres applications
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
PRÉSENTATION / 04/11/23
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/11/23
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/11/23
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/11/23
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/11/23
22
Questions ?