Un pipeline pour Windchill ressemble à celui de n’importe quelle application d’entreprise, à deux différences près : l’application est volumineuse et lente à démarrer, et sa configuration compte autant que son code. Voici la structure que nous utilisons et l’ordre dans lequel nous la construisons.
1. Tout sous contrôle de version
Personnalisations, scripts de build, scripts de déploiement et toute la configuration exportable vivent dans Git. Les changements arrivent par pull request, avec un second relecteur. Ce qui n’est pas dans Git, le pipeline ne peut pas le déployer, et c’est précisément le but.
2. Builder une seule fois
Le pipeline compile les personnalisations à partir d’un commit tagué et produit un artefact versionné unique : un package pour machines virtuelles ou une image Docker pour Kubernetes. Cet artefact est promu sans modification de la recette à la production. Rebuilder pour chaque environnement, c’est ouvrir la porte aux écarts.
3. Tester sur trois niveaux
- Tests unitaires pour la logique métier, exécutés en quelques secondes sans serveur Windchill.
- Tests API qui appellent vos endpoints REST et vos services sur une instance fraîchement déployée.
- Smoke tests qui parcourent quelques flux critiques : créer un article, archiver un document, diffuser une modification.
Windchill étant lent à démarrer, nous gardons l’étape de test sur environnement déployé resserrée. Une suite courte exécutée à chaque merge vaut mieux qu’une longue suite lancée une fois par mois.
4. Promouvoir sur décision
Le déploiement en production attend une approbation, et cette approbation est enregistrée avec les notes de version générées par le pipeline. Les auditeurs apprécient. Les ingénieurs aussi, car la question « qu’est-ce qui a changé, et qui l’a validé ? » trouve sa réponse en un seul endroit.
5. Vérifier et garder une porte de sortie
Après le déploiement, le pipeline contrôle les endpoints de santé et relance les smoke tests. Le rollback redéploie l’artefact précédent. Nous le testons régulièrement, car un rollback qui n’a jamais tourné est un espoir, pas un plan.
Par où commencer
Si vos mises en production sont manuelles aujourd’hui, commencez par les étapes 1 et 2 : Git et un build automatisé. Ce sont elles qui éliminent le plus de risque pour le moins d’effort, et toutes les étapes suivantes reposent sur elles.