Versionner ses projets TIA Portal avec Git : le guide pratique

Le dossier que tout automaticien connaît

Ouvrez le serveur de fichiers de n'importe quel bureau d'études en automatisme. Vous y trouverez presque toujours la même chose :

• Projet_final.zap
• Projet_final_v2.zap
• Projet_final_v2_OK.zap
• Projet_final_v2_OK_vraiment.zap

Ce n'est pas de la négligence. C'est la seule méthode qui fonctionne sans outil : on archive le projet, on ajoute une date ou un suffixe, et on espère ne jamais avoir à répondre à la question « qu'est-ce qui a changé entre la version qui tournait et celle qui ne tourne plus ? ».

Les développeurs logiciels ont réglé ce problème il y a une vingtaine d'années avec Git. La bonne nouvelle, c'est que TIA Portal sait aujourd'hui travailler avec Git. La mauvaise, c'est qu'il ne suffit pas de poser son projet dans un dépôt.

Pourquoi on ne met pas un projet TIA Portal tel quel dans Git

Git a été conçu pour du texte. Il compare les fichiers ligne par ligne, montre ce qui a été ajouté ou supprimé, et fusionne le travail de deux personnes quand elles n'ont pas touché aux mêmes lignes.

Un projet TIA Portal, lui, est un ensemble de fichiers binaires. Vous pouvez techniquement le placer dans un dépôt Git, mais vous n'y gagnez presque rien :

• Git voit que le fichier a changé, sans pouvoir dire quoi.
• Deux modifications faites en parallèle ne peuvent pas être fusionnées : il faut choisir l'une ou l'autre.
• Le dépôt grossit à chaque enregistrement, parce que chaque version est stockée presque en entier.

Autrement dit, vous obtenez une archive datée plus compliquée que la précédente.

Ce dont on a vraiment besoin

Avant de parler d'outil, il faut poser le besoin. Dans un projet automate, la gestion de versions doit permettre de :

• savoir précisément ce qui a changé entre deux versions, bloc par bloc ;
• savoir qui a fait la modification, quand, et pourquoi ;
• revenir à une version précédente sans écraser le reste ;
• travailler à plusieurs sur le même projet sans se marcher dessus.

Pour y arriver, il faut que le programme existe sous une forme que Git sait lire : des fichiers, un par objet.

La solution prévue par Siemens : l'interface VCI

Depuis TIA Portal V16, Siemens fournit une interface de contrôle de version, appelée VCI pour Version Control Interface. Son principe est simple.

Vous créez un workspace : un dossier ordinaire sur votre disque, relié au projet. Vous y exportez les objets de votre programme. Chaque bloc, chaque table de variables, chaque type de données devient un fichier, au format XML pour l'essentiel. Ce dossier peut être un dépôt Git.

L'éditeur VCI affiche alors deux colonnes : le projet d'un côté, le workspace de l'autre. Pour chaque objet, il indique si les deux sont identiques ou si l'un est plus récent que l'autre, et il permet de synchroniser dans un sens ou dans l'autre.

Git, de son côté, ne voit que des fichiers texte. Il peut donc faire son travail : comparer, historiser, fusionner.

La méthode pas à pas

1. Créer le workspace. Dans l'arborescence du projet, ouvrez l'entrée « Version Control Interface », ajoutez un workspace et associez-le à un dossier vide.

2. Initialiser le dépôt. Dans ce dossier, avec votre client Git habituel ou en ligne de commande :

cd C:\Projets\Machine_12\workspace
git init

3. Exporter les objets. Dans l'éditeur VCI, faites glisser vos blocs, vos tables de variables et vos types de données du projet vers le workspace. Les fichiers apparaissent dans le dossier.

4. Enregistrer la première version.

git add .
git commit -m "Version initiale après mise en service"

5. Au quotidien. Vous modifiez dans TIA Portal, vous synchronisez les objets modifiés vers le workspace, puis vous enregistrez dans Git avec un message qui dit ce que vous avez fait.

6. Pour revenir en arrière. Vous restaurez l'ancienne version des fichiers dans Git, puis vous synchronisez du workspace vers le projet. Pensez à recompiler ensuite.

Les limites à connaître

Cette méthode ne remplace pas tout. Mieux vaut le savoir avant de s'y engager.

• Tout le projet n'est pas couvert. L'interface VCI s'occupe du programme : blocs, tables de variables, types de données. La configuration matérielle et les écrans IHM ne suivent pas le même chemin. Vérifiez ce que votre version prend en charge.
• Le XML n'est pas fait pour être lu. Une différence dans un bloc en SCL reste compréhensible. Dans un bloc en Ladder, elle demande de l'habitude.
• Il faut de la discipline. Le projet et le workspace sont deux choses distinctes. Si vous oubliez de synchroniser avant d'enregistrer, votre dépôt ne reflète plus la réalité.

Pour ces raisons, gardez une archive complète du projet à chaque jalon : essais en atelier, mise en service, livraison. Git historise le programme, l'archive garantit que vous pouvez tout rouvrir.

Trois règles qui changent tout en équipe

Un enregistrement, une modification expliquée. « Ajout du verrouillage de la porte 3 » est utile dans deux ans. « Modifs » ne l'est pas.

Un repère par machine livrée. Posez une étiquette Git à chaque version installée chez un client. Le jour où il appelle, vous savez exactement ce qui tourne chez lui.

Une archive complète à chaque jalon. Git et l'archive ne s'opposent pas, ils se complètent.

L'alternative : le VCS de T-IA Connect

L'interface VCI fait le travail, mais elle laisse beaucoup de gestes à la main : exporter, synchroniser, penser à enregistrer. C'est précisément ce que nous avons voulu supprimer dans T-IA Connect, avec une fonction que nous appelons VCS, pour Version Control System.

Le principe reste le même : Git, et des fichiers lisibles. Ce qui change, c'est tout ce qui se passe autour.

• L'export est automatique. T-IA Connect exporte lui-même le projet vers le dépôt, et seulement ce qui a été modifié.
• Il couvre plus que le programme. En plus des blocs, des tables de variables et des types de données, il historise les tables de visualisation et la configuration matérielle de chaque appareil.
• Les différences sont propres. Les fichiers XML sont normalisés avant d'être enregistrés : les horodatages et les identifiants générés, qui changent à chaque export sans que rien n'ait bougé, sont retirés. Un bloc que vous n'avez pas touché n'apparaît pas comme modifié.
• Un point de sauvegarde avant chaque opération sensible. T-IA Connect peut enregistrer automatiquement l'état du projet avant une compilation et avant un chargement dans l'automate. Si quelque chose tourne mal, la version d'avant existe.
• Tout Git est là. Historique, comparaison, branches, fusion, restauration, et synchronisation avec un serveur distant comme GitLab, GitHub ou Gitea.

Et surtout, tout cela se pilote de trois façons : depuis l'interface de T-IA Connect, par son API REST, ou en le demandant à un assistant IA. « Montre-moi ce qui a changé dans le bloc du convoyeur depuis la mise en service » devient une question à laquelle on obtient une réponse. L'assistant propose, vous validez : les opérations qui modifient le projet ou le dépôt demandent votre accord.

Une précision : la restauration porte sur le programme, c'est-à-dire les types de données, les tables de variables et les blocs. La configuration matérielle est historisée pour pouvoir la comparer, pas pour être réimportée automatiquement. La règle de l'archive complète à chaque jalon reste donc valable.

En résumé

• Un projet TIA Portal placé tel quel dans Git n'apporte presque rien.
• L'interface VCI, disponible depuis la V16, exporte le programme en fichiers que Git sait comparer.
• La méthode tient en six étapes et ne demande aucun outil exotique.
• Elle ne couvre pas tout le projet : gardez une archive complète à chaque jalon.
• T-IA Connect automatise cette méthode avec sa fonction VCS et l'étend à la configuration matérielle.

Et vous, comment versionnez-vous vos projets aujourd'hui ? Dites-le en commentaire.