La compatibilité ascendante

Cobos est un produit composé d’une partie client (les plug-ins eclipse) et d’une partie serveur (un ensemble de scripts sur un serveur en fait).

Depuis le tout début du projet, nous avons décidé de donner la possibilité à nos utilisateurs de faire les montées de version client et les montées de version serveur indépendamment. ils ont ainsi tout leur temps pour faire évoluer les postes client, valider une nouvelle version serveur, la mettre en ligne pour quelques utilisateurs bien choisis, bref, tout que ce qui rend la vie Devops meilleure…

Comment avons-nous fait, me direz-vous ?

Eh bien, nous nous sommes appuyés sur ce que l’on appelle la compatibilité ascendante (concept bien connu de nos amis d’IBM car ils se sont engagés la dessus dans les années 60 quand ils ont conçus l’architecture mainframe)

compatibilité ascendante ? il s’agit en fait de compatibilité ascendante ET descendante (cf. https://fr.wikipedia.org/wiki/Compatibilit%C3%A9_ascendante_et_descendante)

Définissons la compatibilité descendante :
Le nouveau serveur est compatible avec la version cliente précédente
Le nouveau client est compatible avec la version serveur précédente

Compatibilité ascendante :
l’ancien client est compatible avec la nouvelle version serveur
l’ancienne version serveur est compatible avec la nouvelle version client

En fait, c’est quand on développe une nouvelle version qu’il faut se poser la question. (Je connais des développeurs qui se sont fait des noeuds au cerveau avec ça, lol)

Pourtant, ce n’est pas si compliqué que ça finalement, il faut juste faire un peu attention.

1er point / connaitre la version de l’autre composant :
Le serveur annonce au client son niveau de version lors de la connection.
Le client annonce son niveau de version lorsqu’il envoie une requête au serveur (toutes les requêtes sont donc marquées avec la version du client).

2eme point / s’adapter à la version du partenaire :
La, c’est un peu plus compliqué car on ne peut pas faire n’importe quoi.
D’après ce que l’on a dit précédemment , il y’aurait 4 cas. Voyons voir ça de plus près :
Рcot̩ client :
Si j’ai en face de moi un serveur plus ancien, je dois adapter certaines de mes requêtes pour être conforme au format attendu et masquer dans l’interface les fonctionnalités non disponibles coté serveur.
Si le serveur est à la dernière version, nous avons la même version , tout va bien.
Si le serveur est à une version supérieure, c’est son problème, pas le mien.
Рcot̩ serveur :
Si j’ai en face de moi un client plus ancien, il faut que je continue à traiter ses requêtes « à l’ancienne » pour respecter la version précédente du protocole applicatif.
Si le client est à la même version, tout va bien.
Si le client est à une version supérieure, c’est à lui de faire attention, ce n’est pas mon problème.

Ben, il n’y a que 2 cas finalement – ou il y en 6 – ? Ce que l’on remarque, c’est que la compatibilité ascendante est assurée par la compatibilité descendante du partenaire – je vous laisse y réfléchir – Il n’y a donc effectivement que 2 cas à prendre en compte.

Pour Cobos, nous avons fait un choix basé sur des principes simples (mais contraignants):
Рnous supportons 2 versions majeures (version courante et version pr̩c̩dente)
– nous garantissons que la version courante sera supportée par la version suivante (je redis exactement la phrase précédente mais c’est mieux si c’est écrit)
– il n’y a donc pas de changement de protocole applicatif entre 2 versions majeures, nos API doivent de ce fait être bien conçues pour être les plus stables possibles – ne pas hésiter à prévoir un peu trop large au départ, c’est tout un art… -.

et voila !

Gérer ses sources COBOL mainframe sous Git ? Why not ?

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 !