Scripts personalizados

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.

Dentro do framework Behavior Extensibility, os scripts são códigos Python executados no servidor, no contexto da plataforma Altium 365. Ao contrário de extensões compiladas ou da automação completa de workflows, os scripts são intencionalmente leves: um único arquivo, um contrato de entrada/saída definido e um propósito específico. Eles podem ser acionados manualmente, chamados a partir de hooks, incorporados em workflows como etapas ou agendados para execução recorrente.

Os scripts compartilham a mesma infraestrutura de extensibilidade que checks, hooks e blocos de workflow – eles têm acesso aos dados do Workspace, podem chamar sistemas externos e seus resultados podem alimentar outras partes do pipeline de automação. A diferença está no escopo: um script faz uma coisa, faz isso de forma limpa e pode ser iterado rapidamente.

Para Que os Scripts São Usados neste Contexto

• Targeted automation – um script que é executado uma vez quando acionado – normalizar valores de parâmetros de componentes em uma biblioteca, gerar um relatório personalizado a partir de dados do Workspace, enviar um conjunto de dados para um sistema externo após um release. Operações focadas que não precisam ser conectadas ao framework completo de checks ou workflows.

• Data transformation – scripts são a ferramenta certa quando os dados precisam ser remodelados entre sistemas – convertendo estruturas de dados do Altium em um formato esperado por uma API externa, ou transformando dados recebidos antes de serem gravados no Workspace. Uma lógica de transformação limpa em um script é mais fácil de testar e manter do que uma transformação oculta dentro de um workflow maior.

• Policy enforcement, lightweight – para regras de aplicação que não precisam ser executadas em pontos de verificação automáticos – regras que um líder de equipe executa antes de uma revisão de marco, verificações invocadas sob demanda em vez de a cada commit – um script é mais apropriado do que um check completo registrado em um evento da plataforma. A sobrecarga da infraestrutura completa de checks não se justifica quando o acionamento é intencional e manual.

• Building blocks for larger automation – os scripts podem ser chamados a partir de hooks e blocos de workflow, tornando-se unidades reutilizáveis dentro de automações maiores. Um script que consulta, por exemplo, uma lista externa de fornecedores aprovados pode ser chamado por vários checks e hooks diferentes sem duplicar a lógica. O script é responsável pela interação com o sistema externo; o check ou hook é responsável pela decisão de política.

Scripts vs. Outros Primitivos de Behavior Extensibility

Os scripts não substituem checks, hooks ou blocos de workflow – eles são um recurso complementar com uma função diferente:

Checks são conectados a eventos de validação da plataforma e executados automaticamente em pontos de verificação definidos. Scripts são executados quando invocados explicitamente.

Hooks respondem a eventos do ciclo de vida da plataforma e são disparados automaticamente. Scripts são chamados deliberadamente – por um usuário, por um agendamento ou de dentro de outro recurso de automação.

Blocos de workflow são etapas reutilizáveis dentro de definições de workflow. Scripts podem implementar a lógica chamada por um bloco de workflow, mas um script sozinho não é uma etapa de workflow.

Comece com um script quando o requisito for uma operação focada, sob demanda ou agendada. Mova a lógica para um check ou hook quando ela precisar ser executada automaticamente em eventos da plataforma. Envolva-a em um bloco de workflow quando ela precisar ser composta em processos estruturados de várias etapas.

Manutenção e Iteração

Scripts são arquivos Python – ficam em controle de versão como qualquer outro código. Como são interpretados e não exigem uma etapa de build, a iteração é rápida: altere o script, faça o deploy, teste. Isso faz dos scripts o ponto de partida ideal quando os requisitos exatos ainda não estão totalmente definidos, ou quando a lógica precisa evoluir rapidamente em resposta ao uso real.

Um script que começa como uma ferramenta utilitária para uma única pessoa frequentemente cresce e se torna uma infraestrutura compartilhada pela equipe. Quando um script chega a esse ponto – usado por várias pessoas, cobrindo um processo crítico, com expectativa de confiabilidade – vale a pena investir em uma estrutura adequada: validação de entrada, tratamento de erros, logging e, potencialmente, migração para um check ou hook mais formal, caso a execução automática passe a ser necessária.