Relatorio de Acompanhamento da Configuração de Software
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 26/09 | 1.0 | Introdução, acompanhamento da política de commits e uso de issues | Marcelo Augusto |
Este relatório tem como objetivo dispor como se ocorreu o acompanhamento dos seguintes pontos:
- Política de commits
- Política de branches
- Uso de issues
Foi cobrado do grupo de desenvolvimento que todos os commits deveriam ter a estrutura definida no plano de gerenciamento de configuração de software. Como pode-se ver na imagem acima, por exemplo, os commits da UC02-MainTainPatient seguiram a estrutura especificada. Caso houvessem algum commit identificado de forma não padrão, o membro que fez o dado commit recebia uma advertência.
A política de branch foi monitorada pela equipe de GPP durante a execução de todo o projeto. As branchs foram criadas a partir da devel e em seguida a equipe de MDS passou a utilizar uma branch para cada caso de uso. Sendo até o presente momento desta imagem o projeto conta com 7 branchs.
As branchs que existem até o momento são as duas principias master que é a branch de produção e devel que é a branch de desenvolvimento onde ocorreu todos os merges dos casos de uso para depois de passarem nos testes e na integração contínua serem enviados para a branch de produção. As outras branchs representam os casos de uso manter paciente, manter profissional de saúde e login. A equipe de GPP necessitou criar outras duas branchs uma delas a Refactoring que foi onde a equipe durante a última(22/09). A necessidade desta branch se deu para explicar os testes para equipe de MDS, explicar e corrigir quais foram os erros encontrados nos códigos da equipe de MDS.
A última branch a ser criada no projeto foi a Template, o motivo da criação desta é devido a necessidade de aplicar o templete escolhido pela equipe de GPP/MDS para seguir o protótipo de alta fidelidade validado pelo cliente. Apenas a equipe de GPP commitou nesta branch, pois o template foi aplicado durante uma reunião para que os membros de MDS pudessem ver e aprender como seriam aplicados os próximos.
Alguns commits foram removidos por GPP devido aos mesmos ferirem a política de branch, todos os commits que foram removidos foram previamente avisado a quem tinha realizado. Um exemplo de commit que foi removido porque o mesmo estava dando um merge da devel na branch de caso de uso, sendo que o correto é o merge ir da branch do caso de uso para a devel. Alguns commits feriram a política de branch, mas a equipe de GPP julgou que não seria necessário remove-los. Um commit que não está de acordo com a política é o commit que o integrante de MDS por não ter dado o pull antes de inserir novas modificações foi necessário realizar um merge dentro da branch. Esse último exemplo foi julgado pela equipe de GPP com um impacto mínimo no projeto por isso não foi removido, mas o membro que realizou este merge foi alertado e orientado de como deveria proceder para que isso não acontecesse de novo.
Como especificado no plano de gerenciamento de configuração de software, deveriam ser feita uma issue para caso de uso na Release 1. Além destas issues foi criada uma outra issue para refatoração, issue que foi necessária para que fossem aplicadas as refatorações indicadas no relatório de qualidade Coleta 1.
