Niestandardowe skrypty

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.

W ramach platformy Behavior Extensibility skrypty to uruchamiany po stronie serwera kod Python, wykonywany w kontekście platformy Altium 365. W przeciwieństwie do skompilowanych rozszerzeń lub pełnej automatyzacji workflow, skrypty są celowo lekkie: pojedynczy plik, zdefiniowany kontrakt wejścia/wyjścia i jasno określony cel. Mogą być uruchamiane ręcznie, wywoływane z hooków, osadzane w workflow jako kroki lub uruchamiane cyklicznie według harmonogramu.

Skrypty współdzielą tę samą infrastrukturę rozszerzalności co checks, hooki i bloki workflow — mają dostęp do danych Workspace, mogą wywoływać systemy zewnętrzne, a ich wyniki mogą zasilać inne części potoku automatyzacji. Różnica polega na zakresie: skrypt robi jedną rzecz, robi ją poprawnie i można go szybko rozwijać iteracyjnie.

Do czego służą skrypty w tym kontekście

• Targeted automation – skrypt uruchamiany jednorazowo po wyzwoleniu — normalizuje wartości parametrów komponentów w całej bibliotece, generuje niestandardowy raport na podstawie danych Workspace, wysyła zestaw danych do systemu zewnętrznego po wydaniu. To ukierunkowane operacje, których nie trzeba podłączać do pełnego frameworka checks lub workflow.

• Data transformation – skrypty są właściwym narzędziem, gdy dane trzeba przekształcać pomiędzy systemami — konwertując struktury danych Altium do formatu oczekiwanego przez zewnętrzne API albo przetwarzając dane przychodzące przed zapisaniem ich do Workspace. Przejrzysta logika transformacji w skrypcie jest łatwiejsza do testowania i utrzymania niż transformacja ukryta wewnątrz większego workflow.

• Policy enforcement, lightweight – w przypadku reguł wymuszania, które nie muszą działać w automatycznych punktach kontrolnych — reguły uruchamiane przez lidera zespołu przed przeglądem kamienia milowego, kontrole wywoływane na żądanie zamiast przy każdym commitcie — skrypt jest bardziej odpowiedni niż pełny check zarejestrowany do zdarzenia platformy. Narzut pełnej infrastruktury checks nie jest uzasadniony, gdy wyzwolenie jest celowe i ręczne.

• Building blocks for larger automation – skrypty mogą być wywoływane z hooków i bloków workflow, co czyni je jednostkami wielokrotnego użytku w większej automatyzacji. Skrypt, który na przykład odpytuje zewnętrzną listę zatwierdzonych dostawców, może być wywoływany z wielu różnych checks i hooków bez duplikowania logiki. Skrypt odpowiada za interakcję z systemem zewnętrznym; check lub hook odpowiada za decyzję polityki.

Skrypty a inne prymitywy Behavior Extensibility

Skrypty nie zastępują checks, hooków ani bloków workflow — są uzupełniającym prymitywem o innej roli:

Checks są powiązane ze zdarzeniami walidacji platformy i uruchamiają się automatycznie w zdefiniowanych punktach kontrolnych. Skrypty uruchamiają się wtedy, gdy zostaną jawnie wywołane.

Hooki reagują na zdarzenia cyklu życia platformy i uruchamiają się automatycznie. Skrypty są wywoływane celowo — przez użytkownika, zgodnie z harmonogramem lub z poziomu innego prymitywu automatyzacji.

Bloki workflow to wielokrotnego użytku kroki wewnątrz definicji workflow. Skrypty mogą implementować logikę wywoływaną przez blok workflow, ale sam skrypt nie jest krokiem workflow.

Zacznij od skryptu, gdy wymaganie dotyczy ukierunkowanej operacji wykonywanej na żądanie lub według harmonogramu. Przenieś logikę do checka lub hooka, gdy musi działać automatycznie w odpowiedzi na zdarzenia platformy. Opakuj ją w blok workflow, gdy ma być składana w uporządkowane, wieloetapowe procesy.

Utrzymanie i iteracja

Skrypty są plikami Python — znajdują się w kontroli wersji jak każdy inny kod. Ponieważ są interpretowane i nie wymagają etapu budowania, iteracja jest szybka: zmiana skryptu, wdrożenie, test. To sprawia, że skrypty są właściwym punktem wyjścia, gdy dokładne wymagania nie są jeszcze w pełni zdefiniowane albo gdy logika musi szybko ewoluować w odpowiedzi na rzeczywiste użycie.

Skrypt, który zaczyna jako narzędzie jednej osoby, często z czasem staje się współdzieloną infrastrukturą zespołu. Gdy skrypt osiąga ten etap — jest używany przez wiele osób, obejmuje krytyczny proces i oczekuje się od niego niezawodności — warto zainwestować w odpowiednią strukturę: walidację danych wejściowych, obsługę błędów, logowanie oraz potencjalnie migrację do bardziej formalnego checka lub hooka, jeśli potrzebne stanie się automatyczne wyzwalanie.