Pourquoi Windchill a besoin d’un pipeline
Sur de nombreuses installations, une mise en production consiste encore à copier des fichiers sur des serveurs, à exécuter des commandes tirées d’une page wiki et à espérer que l’environnement de test reflétait vraiment la production. Cela fonctionne… jusqu’au jour où l’ingénieur concerné est en congés. Un pipeline transforme ce savoir en code qui s’exécute de la même façon à chaque fois.
Ce que font nos pipelines
- Build. Compiler et packager les personnalisations à partir d’un commit tagué.
- Test. Lancer les tests unitaires, puis déployer sur un environnement neuf et y exécuter les tests API et les smoke tests.
- Packaging. Produire un artefact versionné unique, ou une image Docker, promu sans modification.
- Promotion. Déployer en recette, puis en production, avec une étape d’approbation et une décision tracée.
- Vérification. Contrôler les endpoints de santé et les principaux flux métier après le déploiement.
- Rollback. Revenir à la version précédente en une seule action, testée régulièrement plutôt que supposée fonctionner.
Infrastructure as code
Serveurs, réseaux, bases de données et clusters sont décrits en Terraform ou Bicep et configurés avec Ansible. Un nouvel environnement de test, c’est une exécution de pipeline, pas un ticket adressé à une autre équipe.
Pas besoin de conteneurs
Un pipeline est rentable aussi sur de simples machines virtuelles. Beaucoup de clients commencent ainsi et passent à Docker et Kubernetes plus tard, avec le même pipeline et une seule étape de déploiement modifiée.