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.
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 suporte
CORREÇÕES
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.
HOTFIX
LANÇAMENTO
Branches de lançamento
Deve ser criado a partir de: develop
Deve ser mesclado de volta para: develop e master
Nomenclatura: release/versão1.0
Criando um branch de lançamento: Branches de lançamento são criados a partir do branch develop. Digamos que o projeto está na versão 1.5.3 e há uma implantação em breve. O estado do branch develop está pronto para a próxima implantação e decidimos que vai se tornar 1.2.0 (ao invés de 1.1.5 ou 2.0.0). Então criamos um branch com o nome da versão que escolhemos.
Depois de criar o branch, a primeira coisa a fazer é aumentar a versão nos arquivos equivalentes e comitar. Podendo ser um composer.json, defines.mk, um version.py, etc. Esta alteração é chamada de bump.
Neste exemplo o script bump-version.sh faz estas alterações, mas podem ser feitas manualmente.
Este branch deve existir por enquanto, até que esteja pronto para ser implantado definitivamente em produção. Pequenas correções são permitidas nele (ao invés do branch develop). Adicionar funcionalidades novas nele são proibidas, apenas correções pontuais desta versão de lançamento.
Finalizando um branch de lançamento: Quando o branch de lançamento estiver pronto para ser implantado em produção, algumas ações precisam ser tomadas. Primeiro o brach de lançamento é mesclado com o branch master (uma vez que cada commit no master é uma nova versão, por definição).
Em seguida este commit deve ser tageado para referência futura para esta versão.
Finalmente, as mudanças feitas no branch de lançamento precisam mescladas de volta no branch develop, para que as versões futuras também possuam as correções feitas neste branch.
Neste momento podem ocorrer alguns conflitos, já que as correções podem mudar a versão dos arquivos, se acontecer, corrija e comite.
Feitos os merges podemos excluir o branch de lançamento, já que não precisamos mais dele.
RELEASE
MELHORIAS
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.
FEATURE
Branches principais
DEVELOP
HOMOLOGAÇÃO
QA
MASTER
TAG
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
O branch master é o branch principal, a HEAD do projeto, nele há somente versões que estão em produção.
ETAPAS:
pré-analise – N1
análise de requisitos - N2
desenvolvimento
testes
homologação
aplica em produção
encerramento
AZURE
controle de versionamento
historico da demanda: da analise até a implantação em produção
toda demanda no N2 passa pelo azure
DEMANDA
GESTÃO DE VERSIONAMENTO
comitê de mudanças
historico de versionamento sempre atualizado no card da demanda
preparo das versões a serem aplicadas em produção
organização e alinhamento de demandaXversão no ambiente de homologação [SVN e OCP]
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.
todos os testes passam por homologação do solicitante e/ou analista
todo teste é documentado
tipos de testes aplicados:
FUNCIONAL
REGRESSÃO
INTEGRADO
UNITÁRIO
EXPLORATORIO
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.
desenvolvimento de correções e melhorias
analise de incidentes e requisições
ANALISE N2
toda analise passa por aprovação do solicitante ou analista responsável
analise de demandas mais estruturadas [melhorias/novas funcionalidade/correções que necessitam de detalhamento]
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.
novo lider de N1
fase 4: melhorias previstas
metricas
Taxa de reabertura
Taxa de escalonamento: Essa métrica mede a porcentagem de demandas que precisam ser escalonados para níveis superiores de suporte devido à complexidade ou falta de recursos da equipe de nível 1. Uma taxa de escalonamento alta pode indicar a necessidade de melhorar a capacitação da equipe.
Número de chamados abertos
Nível de satisfação do cliente
Taxa de resolução no primeiro contato
Tempo médio de resolução
Tempo médio de resposta
controle da qualidade das pré-análises
criação de base de conhecimento baseada nos chamados e duvidas recorrentes
GPT
alinhamentos semanais - organizar agenda
qualidade da entrada da demanda
verificar chamados suspensos
padrão de pré-analise
fase 3: capacitação de equipe
descritivos para encerramento de chamados
aprofundamento nos relatórios do qualitor
repasses pontuais sobre determinados sistemas e funcionalidades
capacitação interno wise
trilhas de analise
fase 2: introdução e acompanhamento
participação nas reuniões de analise/dev/teste - organizar agenda
e-mails de comite/analise/teste
manter dialogo direto com o N2
levantamento de sugestões de melhoria junto a equipe
levantamento de duvidas sistêmicas recorrentes
estudo dos chamados encaminhados para N2 atualmente
reconhecimento da equipe
fase 1: imersão de duas semanas na wise
contato com a equipe de N2 [analistas-devs-testadores]
primeiro contato com o qualitor
acompanhou o processo da demanda após entrada na fila do N2
apresentado aos principais sistemas suportados
