Le code, en dernier recours
La plupart des demandes se traitent avec le modèle standard : soft types, attributs, règles d’initialisation d’objets, cycles de vie et modèles de workflow. Nous explorons toujours cette voie en premier, car chaque ligne de code spécifique est une ligne qu’il faudra porter lors de la prochaine mise à niveau.
Quand le code est la bonne réponse, il prend la forme d’un module petit et ciblé, avec une seule responsabilité, un responsable nommé et une justification écrite juste à côté.
Comment nous construisons une personnalisation
- Dans Git, dans un dépôt qui vous appartient, chaque changement étant relu par un second ingénieur.
- Par un pipeline, jamais compilée sur un serveur ni copiée à la main.
- Avec des tests exécutés sur une instance Windchill jetable avant toute promotion.
- Dans un inventaire qui consigne ce qu’elle fait, quelles API PTC elle utilise et qui la maintient.
Travaux typiques
- Règles de numérotation et de nommage qui vont au-delà de ce que permettent les règles d’initialisation
- Workflows de modification avec revues parallèles, délégation et relances temporisées
- Contrôles de diffusion qui valident une nomenclature avant son passage à l’état suivant
- Rapports et tableaux de bord bâtis sur les données Windchill
- Outils d’administration : chargements en masse, mises à jour de masse et tâches de nettoyage
Compatible mise à niveau par conception
Nous nous appuyons sur les API et points d’extension supportés, ne modifions jamais les fichiers de PTC et enregistrons chaque surcharge dans l’inventaire. À la version suivante, mettre à niveau les personnalisations se résume à un rebuild et une campagne de tests, pas à une enquête.