A l’heure actuelle, le back office de la majeure partie des grandes entreprise mondiales est géré par des applications COBOL tournant sur mainframe.
La majeure partie de ces applications ont un point commun : elles sont gérées via un outillage datant des années 80/90 assurant en priorité le build et le déploiement et de manière beaucoup plus primaire le versionning.
En effet, la gestion de version, quand elle existe, est techniquement réalisée au niveau des composants et non au niveau applicatif. Les sites ne mettent pas en oeuvre la gestion de branches même si, en théorie, cette fonctionnalité est disponible. On ne gère donc pas de version d’application.
Par opposition, les applications du monde « moderne » (Java, .Net, etc…) sont gérées dans des outils assurant un versionning complet de type Git/SVN avec gestion de branches, build automatique, etc… Le point faible actuellement de ce coté est plutot l’aspect déploiement qui est une clé du monde DevOps.
Ce qui est très différent entre les 2 mondes :
– sur mainframe, on ne build et déploie que des composants individuels en mode petit train (une modif avant l’autre, un peu tout le temps – pas de développement en parallèle, pas de version de logiciel).
– sur mainframe, les sources sont stockés en vrac dans des bibliothèques pouvant contenir jusqu’à 40 000 sources. Il est impensable de mettre tout dans un dépot Git et de le cloner sur chaque poste de développeur !
Ceci étant, qu’est-ce qu’il faudrait faire pour mettre mes sources COBOL mainframe sous Git ?
1) Découper la poubelle qui me sert de repository (je plaisante, bien sur) en applications de taille raisonnable, identifier les modules communs et les traiter comme des applications aussi.
2) Etre capable de lancer les procédures de compilation et de transfert mainframe (build and deploy) depuis des postes externes (eclipse et serveur jenkins)
3) Former les développeurs à l’utilisation de Git (c’est pas gagné!)
4) Oublier ISPF pour travailler sous eclipse !
Affirmer qu’il n’existe qu’une seule version logicielle et qu’il n’existe pas de branches parallèles sur les mainframe est erroné, il n’y a certes généralement pas un grand nombre de versions qui cohabitent, mais, le plus souvent, on a a minima un circuit projet (souvent deux) et un circuit maintenance à chaud pour les incidents.
Soit deux ou trois branches et autant de versions en parallèle
Bonjour,
Veuillez excuser le délai de réponse à votre question mais les vacances sont passées par la…
La réponse :
Nous avons développé des scripts permettant de lancer la build et le promote SCLM depuis Cobos. Ces scripts peuvent tout à fait être lancés depuis Jenkins.
Nous pouvons donc considérer que le point 2) n’est pas non plus un problème
Bonjour,
Nous utilisons SCLM comme gestionnaire de source / librairie d’exécution (au moins une librairie par environnement).
Côté monde open, nous utilisons SVN/jenkins pour produire nos livrables et les déployer (au moins en intégration).
Ma question concerne le deuxième point (« 2) Etre capable de lancer les procédures de compilation et de transfert mainframe (build and deploy) depuis des postes externes (eclipse et serveur jenkins) ») :
Qu’existe-t-il à votre connaissance comme solution technique pour mettre en place SVN -> Jenkins -> SCLM ? C’est à dire mettre jenkins comme : extracteur de sources cobol depuis SVN, alimentation de SCLM, déclencheur de compilation + promote dans SCLM.
Il est existe de grosses solutions packagés (IBM, microfocus) mais j’aimerai identifier la difficulté de la mise en Å“uvre d’une solution moins chère, moins élaborée mais qui réponde au principe d’architecture « SVN -> Jenkins -> SCLM ».
Pour simplifier la réponse, considérons que les points 1) 3) et 4) ne sont pas un problème
Merci pour votre aide !