Scripts personnalisés

Scripts are the lightest-weight entry point into Behavior Extensibility – Python code that runs on the platform server and can be triggered, scheduled, or called from within larger automation flows.

Dans le cadre de Behavior Extensibility, les scripts sont des scripts Python côté serveur qui s’exécutent dans le contexte de la plateforme Altium 365. Contrairement aux extensions compilées ou à l’automatisation complète des workflows, les scripts sont volontairement légers : un seul fichier, un contrat d’entrée/sortie défini et un objectif ciblé. Ils peuvent être déclenchés manuellement, appelés depuis des hooks, intégrés dans des workflows sous forme d’étapes ou planifiés pour s’exécuter de manière récurrente.

Les scripts partagent la même infrastructure d’extensibilité que les checks, les hooks et les blocs de workflow : ils ont accès aux données du Workspace, peuvent appeler des systèmes externes, et leurs résultats peuvent alimenter d’autres parties du pipeline d’automatisation. La différence réside dans leur portée : un script fait une seule chose, la fait proprement, et peut être itéré rapidement.

À quoi servent les scripts dans ce contexte

• Targeted automation – un script qui s’exécute une seule fois lorsqu’il est déclenché – normaliser les valeurs de paramètres des composants dans une bibliothèque, générer un rapport personnalisé à partir des données du Workspace, envoyer un jeu de données vers un système externe après une release. Des opérations ciblées qui n’ont pas besoin d’être intégrées à l’ensemble du framework de checks ou de workflow.

• Data transformation – les scripts sont l’outil approprié lorsqu’il faut remanier les données entre systèmes – convertir les structures de données Altium dans un format attendu par une API externe, ou transformer des données entrantes avant leur écriture dans le Workspace. Une logique de transformation propre dans un script est plus facile à tester et à maintenir qu’une transformation enfouie dans un workflow plus vaste.

• Policy enforcement, lightweight – pour des règles d’application qui n’ont pas besoin d’être exécutées à des points de contrôle automatiques – des règles qu’un chef d’équipe exécute avant une revue de jalon, des checks invoqués à la demande plutôt qu’à chaque commit – un script est plus approprié qu’un check complet enregistré sur un événement de la plateforme. La surcharge de l’infrastructure complète de check ne se justifie pas lorsque le déclenchement est intentionnel et manuel.

• Building blocks for larger automation – les scripts peuvent être appelés depuis des hooks et des blocs de workflow, ce qui en fait des unités réutilisables au sein d’automatisations plus larges. Un script qui interroge, par exemple, une liste externe de fournisseurs approuvés peut être appelé depuis plusieurs checks et hooks différents sans dupliquer la logique. Le script gère l’interaction avec le système externe ; le check ou le hook gère la décision de politique.

Scripts vs autres primitives de Behavior Extensibility

Les scripts ne remplacent pas les checks, les hooks ou les blocs de workflow – ce sont des primitives complémentaires ayant un rôle différent :

Les checks sont reliés aux événements de validation de la plateforme et s’exécutent automatiquement à des points de contrôle définis. Les scripts s’exécutent lorsqu’ils sont explicitement invoqués.

Les hooks répondent aux événements du cycle de vie de la plateforme et se déclenchent automatiquement. Les scripts sont appelés délibérément – par un utilisateur, selon une planification, ou depuis une autre primitive d’automatisation.

Les blocs de workflow sont des étapes réutilisables à l’intérieur des définitions de workflow. Les scripts peuvent implémenter la logique appelée par un bloc de workflow, mais un script seul n’est pas une étape de workflow.

Commencez par un script lorsque le besoin correspond à une opération ciblée, à la demande ou planifiée. Déplacez la logique dans un check ou un hook lorsqu’elle doit s’exécuter automatiquement lors d’événements de la plateforme. Encapsulez-la dans un bloc de workflow lorsqu’elle doit être composée dans des processus structurés en plusieurs étapes.

Maintenance et itération

Les scripts sont des fichiers Python – ils sont placés sous contrôle de version comme n’importe quel autre code. Comme ils sont interprétés et ne nécessitent pas d’étape de build, l’itération est rapide : modifier le script, déployer, tester. Cela fait des scripts le bon point de départ lorsque les exigences exactes ne sont pas encore entièrement définies, ou lorsque la logique doit évoluer rapidement en réponse à l’usage réel.

Un script qui commence comme un utilitaire personnel devient souvent une infrastructure partagée par l’équipe. Lorsqu’un script atteint ce stade – utilisé par plusieurs personnes, couvrant un processus critique, attendu comme fiable – il vaut la peine d’investir dans une structure appropriée : validation des entrées, gestion des erreurs, journalisation, et éventuellement migration vers un check ou un hook plus formel si un déclenchement automatique devient nécessaire.