Fluxos de trabalho personalizados

Custom workflows are how you define deterministic, auditable pipelines for hardware development – so that design work moves through validation and release by rule, not by memory.

No desenvolvimento de software, CI/CD significa que toda mudança é verificada automaticamente, e nada é enviado até que as verificações sejam aprovadas. As equipes de hardware sempre tiveram o equivalente – execuções de ERC, revisões de BOM, verificações de regras de projeto, aprovações de liberação – mas, historicamente, essas verificações dependiam de a pessoa certa estar disponível e se lembrar de executá-las. Os fluxos de trabalho personalizados no Altium 365 eliminam essa lacuna: eles definem o que deve acontecer, em que ordem, e o que precisa ser aprovado antes que a próxima etapa comece.

Um fluxo de trabalho conecta a sequência de eventos – commits, revisões, validações, liberações – em um pipeline estruturado que é executado automaticamente. O engenheiro não gerencia o processo. O processo gerencia a si mesmo.

O que os fluxos de trabalho personalizados definem

• Stage sequences and gates – um fluxo de trabalho define os estágios pelos quais um projeto ou componente passa e o que deve ser verdadeiro em cada etapa de controle antes que a próxima fase comece. Um projeto que falha na validação não pode avançar para a liberação. Um componente que não concluiu a qualificação não pode ser aprovado para a biblioteca. A etapa de controle é aplicada pela plataforma, não por um revisor que se lembrou de verificar.

• Automated validation at each stage – cada estágio de um fluxo de trabalho pode ter verificações de validação associadas a ele. Quando o projeto chega a esse estágio, as verificações são executadas automaticamente. Os resultados são registrados – o que foi executado, em relação a qual revisão, o que foi encontrado, quando. Quando algo dá errado no protótipo ou na produção, você não precisa reconstruir decisões com base na memória ou em threads de e-mail. O registro está lá.

• Release pipelines – todo o caminho do projeto até o artefato de liberação validado – validação, geração de saídas, upload para o Workspace – pode ser definido como um fluxo de trabalho. Liberações que pulam etapas ou contornam verificações tornam-se estruturalmente impossíveis, e não apenas desencorajadas. Nada é enviado sem passar pelas etapas de controle que você definir.

• Notification and coordination – os fluxos de trabalho definem quem é notificado em cada estágio e qual ação é exigida dessas pessoas. Um estágio de revisão de projeto notifica os revisores designados; a etapa de liberação aguarda a aprovação deles. A coordenação está incorporada à definição do processo, e não é gerenciada por e-mail ou chat.

O valor de tornar os processos explícitos

A maioria das organizações de hardware tem processos de liberação que existem como entendimento compartilhado – todos sabem, em linhas gerais, o que deve acontecer, mas os detalhes variam conforme o projeto, o engenheiro e o nível de pressão de prazo. Quando uma etapa é perdida, é porque alguém esqueceu ou decidiu que ela não era necessária daquela vez.

Os fluxos de trabalho personalizados transformam o processo em um artefato de primeira classe. Ele é definido uma vez, aplicado de forma consistente e imposto automaticamente. Engenheiros novos seguem o mesmo processo que engenheiros experientes. O processo não se degrada sob pressão de prazo. As exceções ficam visíveis porque exigem uma substituição explícita, e não apenas a decisão de pular uma etapa.

Quando investir em fluxos de trabalho personalizados

Os fluxos de trabalho agregam valor de forma proporcional à frequência com que o processo é executado e à gravidade das falhas. Uma equipe que libera um projeto por trimestre para um fabricante de protótipos mais tolerante pode não precisar de automação formal de fluxo de trabalho. Uma equipe que libera semanalmente para manufatura aeroespacial ou médica – onde uma falha de processo tem custo real – obtém retorno imediato.

O outro sinal é quando a mesma falha de processo continua acontecendo. Se projetos chegam à liberação sem a mesma verificação, ou a mesma aprovação é esquecida, ou o mesmo tipo de saída é gerado com configurações erradas – isso é um problema de fluxo de trabalho, e a correção é tornar o comportamento correto automático, em vez de depender de as pessoas se lembrarem dele.