Novo modelo de Liberação Versão Release Candidate.

Esse Documento tem a finalidade de explicar o funcionamento do novo modelo de Liberação Versão Release Candidate.

Todos os clientes Linx DMS.

O que é uma Liberação Versão Release Candidate

A Versão Release Candidate é uma etapa controlada e antecipada de disponibilização de uma nova versão do sistema para um grupo restrito de clientes parceiros.

Essa liberação ocorre antes da disponibilização geral ao mercado e tem comoprincipais objetivos:

• Reduzir bugs em produção;
• Validar cenários reais de operação;
• Melhorar processo de release;
• Aumentar confiabilidade das versões;
• Envolver clientes estratégicos no processo de evolução.

Fluxo Macro da Liberação Versão Release Candidate

Cronograma

Fluxo Macro de Atendimento

Fluxo de Atendimento de Incidentes

1. Identificação do Incidente

O cliente identifica um comportamento inesperado, erro ou falha no sistema durante a utilização da nova versão do Linx DMS.
O cliente deverá reunir, sempre que possível:

• Descrição do problema;
• Passo a passo para reprodução;
• Prints ou evidências;
• Impacto na operação.

2. Comunicação do Incidente

O cliente deverá registrar o incidente através do canal específico, definido para centralizar e priorizar os atendimentos.

3. Recebimento pelo Analista de Qualidade

O Analista de Qualidade responsável pelo programa receberá o incidente registrado e realizará a triagem inicial.

Nesta etapa será verificado:

• Se todas as informações necessárias foram fornecidas;
• Se o incidente está relacionado à nova versão;
• Classificação da severidade do problema;
• Se necessário, o analista poderá solicitar informações adicionais ao cliente.

4. Validação e Reprodução do Problema

O Analista de Qualidade realizará:

• Reprodução do cenário reportado;
• Validação técnica do incidente;
• Confirmação do comportamento reportado.

Caso o problema seja confirmado, será aberto uma issue no Jira para o time de Desenvolvimento.

5. Encaminhamento para Desenvolvimento

Após validação, o incidente será encaminhado para o time de desenvolvimento responsável.

O registro deverá conter:

• O que o sistema está fazendo;
• O que o sistema deveria fazer;
• Existe paliativa;
• Observações e/ou informações adicionais;
• Evidências;
• Impacto operacional;
• Prioridade de correção.

6. Correção pelo Time de Desenvolvimento

O time de desenvolvimento realizará:

• Análise técnica do problema;
• Implementação da correção;
• Disponibilização da correção para validação.

A correção será então devolvida ao Analista de Qualidade para validação.

7. Validação da Correção (QA)

O Analista de Qualidade executará:

• Validação da correção implementada;
• Testes regressivos relacionados;
• Confirmação de que o problema foi resolvido.

Caso a correção não esteja adequada, o incidente retornará ao desenvolvimento para novos ajustes.

8. Retorno ao Cliente

Após validação da correção, o Analista de Qualidade realizará o retorno ao cliente informando:

• que o problema foi identificado e corrigido;
• instruções para atualização ou aplicação da correção;
• eventual necessidade de validação do cliente.

9. Encerramento do Incidente

O incidente será considerado encerrado quando:

• a correção estiver validada internamente;
• o cliente confirmar a resolução do problema.

O registro permanecerá documentado para acompanhamento da estabilidade da versão.

🎯Benefícios Esperados

✅ Melhoria na Qualidade das Releases;
✅ Redução de Incidentes em Produção;
✅ Maior Estabilidade do Sistema;
✅ Identificação de Cenários Reais de Uso;
✅ Maior Proximidade com Clientes Parceiros.

Em caso de dúvidas sobre o conteúdo deste documento, entre em contato com o Suporte Nacional, através do site cliente.linx.com.br.