Processo de Engenharia e Sustentação de Software - e-SUS AF

1. Visão Geral e Arquitetura em Três Frentes

O ecossistema do e-SUS AF é um sistema de missão crítica para a saúde pública brasileira, utilizado diariamente por municípios, estados e pelo Ministério da Saúde na gestão de estoques, dispensação de medicamentos e integração com a Rede Nacional de Dados em Saúde (RNDS).

Para atender à complexidade operacional e garantir alta disponibilidade sem comprometer a inovação, o modelo de trabalho é organizado em três frentes complementares e desacopladas:

1. Frente 1: Suporte N3 (Triagem Técnica & Investigação Avançada): Composto por 2 membros dedicados à análise aprofundada de logs, reprodução de erros em ambiente de homologação, execução de scripts de dados aprovados e diagnóstico de causa raiz, sem realizar alterações diretas no código-fonte da aplicação.
2. Frente 2: Sustentação (Fluxo Kanban para Incidentes Sev 1 e Sev 2): Célula de engenharia focada na resolução ágil e cirúrgica de defeitos críticos (Hotfixes) e defeitos graves (Bugfixes urgentes), operando com limite de trabalho em progresso (WIP) e esteira curta de entrega contínua.
3. Frente 3: Evolução (Scrum + Release Train 2+1): Time de desenvolvimento focado na implementação de novas histórias de usuário, melhorias e débitos técnicos, operando em ciclos de 2 Sprints de Desenvolvimento (4 semanas) seguidas de 1 Sprint de Estabilização e Homologação (1 a 2 semanas).

Macrofluxo Operacional

flowchart LR
    subgraph Entrada["Canais de Entrada"]
        N1["Suporte N1/N2 (NQS)
Atendimento & Triagem Funcional"]
    end

    subgraph F1["Frente 1: Suporte N3"]
        N3["Suporte N3 (2 membros dedicados)
• Investigação Técnica / Logs
• Reprodução em Homologação
• Scripts de BD Operacionais
• Diagnóstico Causa Raiz"]
    end

    subgraph F2["Frente 2: Sustentação"]
        SUST["Sustentação (Kanban)
• Defeitos Críticos (Sev 1 / Hotfix)
• Defeitos Graves (Sev 2 / Bugfix)
• Célula Dev Focada / Rotação
• Esteira Curta & Releases Patches"]
    end

    subgraph F3["Frente 3: Evolução"]
        EVO["Evolução (Scrum + Release Train)
• 2 Sprints Dev (4 semanas)
• 1 Sprint Estabilização (1-2 sem)
• Novas Features & Bugs Sev 3/4
• Releases Minor/Major (OneFlow)"]
    end

    subgraph Saida["Entrega / Produção"]
        PROD["Ambiente de Produção
• Releases Patches (vX.Y.Z)
• Releases Minor/Major (vX.Y.0)"]
    end

    N1 -->|Escalonamento Técnico| N3
    N3 -->|Defeito Sev 1/2 com alteração de código| SUST
    N3 -->|Defeito Sev 3/4 ou Débito Técnico| EVO
    N3 -->|Resolução sem código / Script| N1
    SUST -->|Hotfixes & Patches| PROD
    EVO -->|Releases Programadas| PROD

2. Princípios Operacionais Fundamentais

O sucesso do modelo de engenharia do e-SUS AF sustenta-se em quatro pilares operacionais essenciais:

2.1. Blindagem de Contexto

A equipe de Evolução é protegida contra interrupções desordenadas causadas por chamados cotidianos de suporte ou dúvidas funcionais. O Suporte N3 e a Célula de Sustentação atuam como filtros estruturados, garantindo que o time de desenvolvimento mantenha foco contínuo e atinja a meta das Sprints. Somente incidentes críticos Sev 1 com protocolo formal de crise (Swarming) autorizam a mobilização extraordinária de membros da Evolução.

2.2. Fluxo Contínuo para Incidentes (Kanban)

Defeitos que paralisam operações nos municípios (Sev 1) ou que afetam funcionalidades essenciais sem solução de contorno (Sev 2) não esperam pelo encerramento de Sprints de semanas. Eles entram imediatamente na esteira Kanban de Sustentação, com priorização no topo da fila, tempo de resposta controlado e publicação ágil de patches (vX.Y.Z+1).

2.3. Previsibilidade do Release Train (Ciclo 2+1)

O desenvolvimento de novas funcionalidades adota a cadência fixa do Release Train: - 2 Sprints de Desenvolvimento (4 semanas): Construção modular de histórias de usuário, testes automatizados e integração contínua na branch main. - 1 Sprint de Estabilização (1 a 2 semanas): Code Freeze em branch temporária (release/*), bateria intensiva de testes de regressão pelo time de QA, homologação funcional pela equipe de Negócio/PO e refinamento técnico do próximo ciclo.

2.4. Rastreabilidade e Qualidade Integrada

Nenhuma alteração de código entra em produção de forma isolada ou sem evidências: - Todo commit e Pull Request está vinculado a uma issue formal (Jira/GitLab/GitHub). - Todos os desenvolvimentos e correções incluem obrigatoriamente testes automatizados (unitários e/ou ponta a ponta). - Todo PR exige Code Review por pares e aprovação do Líder Técnico antes do merge. - O versionamento adota a disciplina do OneFlow, mantendo uma única branch perpétua (main) com tags semânticas auditáveis.

3. Guia de Navegação do Módulo

Explore os capítulos a seguir para conhecer detalhadamente as diretrizes, padrões e procedimentos técnicos de cada etapa do fluxo de trabalho: