Skip to main content
Colocar um processo novo para rodar no Hub segue sempre o mesmo caminho, em duas fases que nunca se misturam: primeiro entender o processo de negócio, depois mapear esse entendimento para a arquitetura do Hub. A ordem importa: nenhuma decisão técnica é tomada antes do processo em si estar bem entendido e validado.

​
Fase 1: o processo de negócio

A primeira fase é uma entrevista estruturada, sempre ancorada no que existe de verdade, nunca em suposição. Quando o processo já roda de algum outro jeito (uma automação legada, uma planilha, um passo a passo manual), a entrevista parte do que já está documentado ou implementado, marcando como pendente só o que de fato ainda não está decidido. O resultado cobre a narrativa do processo, as regras de negócio e suas exceções, quem depende do processo, e os dados que ele manipula, incluindo uma análise obrigatória de dado sensível: toda automação Dom Med lida com dado de saúde e frequentemente com CPF, então essa parte nunca é opcional. Se o processo ainda não tem repositório, é neste ponto, assim que o nome do processo está decidido, que o repositório dommed-{nome-do-processo} é criado, sempre com confirmação explícita antes de qualquer ação real no GitHub.

​
Fase 2: a arquitetura

Com o processo entendido, a segunda fase mapeia essa narrativa para as peças concretas do Hub: como o processo se torna uma Automation com seus parâmetros de entrada, como cada execução se torna um Job, qual a forma do executor que efetivamente processa uma execução, que máquina dedicada ele precisa e para onde vão as credenciais que ele usa. Essa fase reúne os três papéis consultivos do time ao mesmo tempo, cada um cobrindo sua parte: conformidade de arquitetura, infraestrutura, e segurança das credenciais envolvidas. Também é aqui que se decide o formato do resultado que a automação vai produzir, sempre seguindo o mesmo envelope usado por toda automação do Hub (o que a automação processou, um resumo com contagens, e o status de cada item processado), para que o resultado de qualquer automação se leia da mesma forma.

​
Nascer como worker

A automação nova não parte do zero: ela copia, verbatim, a base reutilizável do worker de referência. Essa base tem duas camadas copiáveis: uma com o contrato que toda automação implementa (reivindicar um job, reportar sucesso ou falha, encerrar de forma graciosa) e outra com integrações externas já prontas para automações de saúde ocupacional, hoje três: acesso a arquivos no Google Drive, à API do sistema de gestão de saúde ocupacional usado pelo Hub, e extração estruturada de dados de PDF. Uma automação nova usa o que precisa dessas integrações prontas e só implementa como integração nova o que realmente não existe ainda. Essa cópia direta, sem empacotamento, não é a primeira tentativa: em algum momento o Hub tentou distribuir essa base como um pacote instalável e reverteu, porque a complexidade extra não se pagava. É o padrão comprovado, não teórico: a primeira automação real do Hub em produção nasceu exatamente assim. Por fim, a automação ganha uma máquina dedicada só dela, criada uma única vez, e um README gerado a partir das duas especificações da automação, sempre em linguagem de negócio, descrevendo o que a automação faz, nunca em que fase de desenvolvimento ela está.