Script personalizzati

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.

Nel framework Behavior Extensibility, gli script sono codice Python lato server che viene eseguito nel contesto della piattaforma Altium 365. A differenza delle estensioni compilate o dell'automazione completa dei workflow, gli script sono volutamente leggeri: un singolo file, un contratto di input/output definito e uno scopo mirato. Possono essere attivati manualmente, richiamati dagli hook, incorporati nei workflow come passaggi oppure pianificati per l'esecuzione ricorrente.

Gli script condividono la stessa infrastruttura di estendibilità di check, hook e blocchi di workflow: hanno accesso ai dati del Workspace, possono chiamare sistemi esterni e i loro risultati possono alimentare altre parti della pipeline di automazione. La differenza sta nell'ambito: uno script fa una sola cosa, la fa bene e può essere iterato rapidamente.

A cosa servono gli Script in questo contesto

• Targeted automation – uno script che viene eseguito una volta quando viene attivato – normalizzare i valori dei parametri dei componenti in una libreria, generare un report personalizzato dai dati del Workspace, inviare un dataset a un sistema esterno dopo una release. Operazioni mirate che non devono essere integrate nell'intero framework di check o workflow.

• Data transformation – gli script sono lo strumento giusto quando i dati devono essere rimodellati tra sistemi – convertire le strutture dati di Altium in un formato previsto da un'API esterna oppure trasformare i dati in ingresso prima che vengano scritti nel Workspace. Una logica di trasformazione pulita in uno script è più facile da testare e manutenere rispetto a una trasformazione nascosta all'interno di un workflow più grande.

• Policy enforcement, lightweight – per regole di enforcement che non devono essere eseguite in checkpoint automatici – regole che un team lead esegue prima di una milestone review, controlli richiamati su richiesta invece che a ogni commit – uno script è più appropriato di un check completo registrato su un evento della piattaforma. L'overhead dell'infrastruttura completa dei check non è giustificato quando l'attivazione è intenzionale e manuale.

• Building blocks for larger automation – gli script possono essere richiamati da hook e blocchi di workflow, diventando così unità riutilizzabili all'interno di automazioni più ampie. Uno script che interroga, per esempio, un elenco esterno di fornitori approvati può essere richiamato da più check e hook diversi senza duplicare la logica. Lo script gestisce l'interazione con il sistema esterno; il check o l'hook gestisce la decisione di policy.

Script vs altri elementi primitivi di Behavior Extensibility

Gli script non sostituiscono check, hook o blocchi di workflow: sono un elemento complementare con un ruolo diverso:

I check sono collegati agli eventi di validazione della piattaforma e vengono eseguiti automaticamente in checkpoint definiti. Gli script vengono eseguiti quando sono richiamati esplicitamente.

Gli hook rispondono agli eventi del ciclo di vita della piattaforma e si attivano automaticamente. Gli script vengono richiamati deliberatamente – da un utente, da una pianificazione o dall'interno di un altro elemento di automazione.

I blocchi di workflow sono passaggi riutilizzabili all'interno delle definizioni di workflow. Gli script possono implementare la logica richiamata da un blocco di workflow, ma uno script da solo non è un passaggio di workflow.

Inizia con uno script quando il requisito è un'operazione mirata, su richiesta o pianificata. Sposta la logica in un check o in un hook quando deve essere eseguita automaticamente in corrispondenza di eventi della piattaforma. Racchiudila in un blocco di workflow quando deve essere composta in processi strutturati a più passaggi.

Manutenzione e iterazione

Gli script sono file Python – vengono mantenuti nel controllo versione come qualsiasi altro codice. Poiché sono interpretati e non richiedono una fase di build, l'iterazione è rapida: modifica lo script, distribuiscilo, testalo. Questo rende gli script il punto di partenza giusto quando i requisiti esatti non sono ancora completamente definiti o quando la logica deve evolvere rapidamente in risposta all'uso reale.

Uno script che nasce come utility per una sola persona spesso si trasforma in un'infrastruttura condivisa dal team. Quando uno script arriva a questo punto – usato da più persone, coinvolto in un processo critico, con aspettative di affidabilità – vale la pena investire in una struttura adeguata: validazione degli input, gestione degli errori, logging ed eventualmente migrazione verso un check o un hook più formale se diventa necessaria l'attivazione automatica.