Histórico da Página

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.

Âncora
explicação explicação

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.

Âncora
fluxo fluxo

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

Âncora
cronograma cronograma

Cronograma

Âncora
fluxomacro fluxomacro

Fluxo Macro de Atendimento

Âncora
fluxoincidentes fluxoincidentes

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.

Âncora
benefícios benefícios

🎯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.