DEMANDA

N1

•Análise inicial N1: Equipe analisa o chamado, se necessário, entra em contato com o solicitante para poder detalhar a demanda e encaminhar ao N2 ou para a análise do QA ou Analista Sebrae/PR.

ANALISE N2

analise de demandas mais estruturadas [melhorias/novas funcionalidade/correções que necessitam de detalhamento]

toda analise passa por aprovação do solicitante ou analista responsável

DEV N2

•Desenvolvedor realiza as devidas alterações conforme detalhamento da demanda e libera uma versão para testes.•Encerramento do chamado: O chamado será encerrado somente após a implantação em produção, o mesmo deverá conter as evidências das alterações realizadas.

analise de incidentes e requisições

desenvolvimento de correções e melhorias

TESTES N2

•Testes: Os testes devem ser realizados conforme detalhamento da demanda, com os testes executados, o cliente será acionado para que homologue a alteração e aprove que ela seja aplicada em produção.

tipos de testes aplicados:
FUNCIONAL
REGRESSÃO
INTEGRADO
UNITÁRIO
EXPLORATORIO

todo teste é documentado

todos os testes passam por homologação do solicitante e/ou analista

GESTÃO DE VERSIONAMENTO

organização e alinhamento de demandaXversão no ambiente de homologação [SVN e OCP]

preparo das versões a serem aplicadas em produção

historico de versionamento sempre atualizado no card da demanda

comitê de mudanças

AZURE

toda demanda no N2 passa pelo azure

historico da demanda: da analise até a implantação em produção

controle de versionamento

ETAPAS:
pré-analise – N1
análise de requisitos - N2
desenvolvimento
testes
homologação
aplica em produção
encerramento

O branch master é o branch principal, a HEAD do projeto, nele há somente versões que estão em produção.

O branch develop possui todo código já entregue e as últimas de desenvolvimento para a próxima versão. Quando o código do branch develop é considerado estável e pronto para ser implantado, todas as alterações devem ser mescladas de volta para o branch master

Branches principais

MASTER

DEVELOP

HOMOLOGAÇÃO

Branches de suporte

MELHORIAS

FEATURE

Branches de melhorias
Deve ser criado a partir de: DEVELOP

Deve ser mesclado de volta para: DEVELOP

Nomenclatura: REQ-00000 / INC-00000

Criando um branch de melhoria: Ao iniciar o desenvolvimento de uma funcionalidade, crie um branch a partir do branch develop

Finalizando um branch de melhoria: Uma vez concluído o desenvolvimento no branch, ele deve ser incorporado de volta no branch develop através de um pull request.

LANÇAMENTO

CORREÇÕES

HOTFIX

Branches de correções
Deve ser criado a partir de: master

Deve ser mesclado de volta para: develop e master

Nomenclatura: qa-hotfix

Criando um branch de correção: Branches de correção são criados a partir do branch master. Por exemplo, digamos que a versão corrente é a 1.2.0 e está causando problemas devido a um erro grave em produção. Porém as mudanças no branch develop não estão estáveis ainda. Precisamos criar um branch de correção e começar a corrigir o problema.

Não esqueça de aumentar a versão após criar o branch.
Em seguida corrigir o bug e comitar em um ou mais commits.

Finalizando um branch de correção: Quando finalizados as correções, o branch deve ser mesclado devolta com o branch master, mas também deve ser mesclado com o branch develop, para que as correções sejam incluídas na próxima versão também. O processo é similar ao do branch de lançamento.

Primeiro atualize o master e crie uma tag.

Em seguida inclua a correção no branch develop.

A única excessão a esse processo é quando existe um branch de lançamento, neste caso as alterações devem ser mescladas nele, ao invés de no branch develop. As alterações mescladas no branch de lançamento refletirão no banch develop também, quando forem finalizadas. Se o branch develop precisar da correção imediatamente e não puder esperar a finalização do branch de lançamento você pode mesclar com ele também.

Finalmente, removemos o branch já mesclado.

Branches de melhorias são usados para desenvolver novas funcionalidades para o próximo lançamento. Em excência, um branch de melhoria existe apenas enquanto está em desenvolvimento, devendo ser mesclado ao branch develop, assumindo que entrará no próximo lançamento, ou descartado caso não seja útil ou seja um experimento.

Branches de correções são muito parecidos com branches de lançamentos em sua concepção, pois tem o mesmo objetivo de prepara uma versão para produção, embora não planejada. Eles surgem da necessidade de agir imediatamente em uma versão de produção já implantada. Quando um bug crítico ocorre em produção um branch de correção precisa ser criado a partir da tag correspondente.
A ideia é que o time que está trabalhando na próxima versão no branch develop possa continuar enquanto alguém prepara uma correção.