Políticas de Repositório

Políticas de Git

Destacamos abaixo informações iniciais aos contribuintes sobre a configuração do repositório. Orientações completas sobre as políticas e padrões aqui seguidos podem ser obtidas no Plano de Gerenciamento de Configuração de Software.

Commits

• Commits devem ser redigidos no idioma inglês
• Devem ser simples e concisos, possuindo títulos curtos
• Devem iniciar com letras maiúsculas.
• Devem iniciar com um verbo no infinitivo informando seu objetivo. Ex: "Create new home Screen"

Branches

As branches do projeto seguirão o padrão de desenvolvimento baseado no GitFlow, padrão desenvolvido por Vincent Driessen para facilitar a escalabilidade do time de desenvolvimento, fator importante para o projeto durante a junção das equipes de GPP e MDS.

As branches devel e master têm papel importante no fluxo seguido. Portanto, nenhuma dessas deve receber um commit diretamente pelo time de desenvolvimento de nenhuma Feature ou Correção.

Para cada Feature uma nova branch deve ser criada com base no último commit da Devel. O nome da branch deve seguir o modelo: UC_[NomeDoCasoDeUsoEmCamelCase]

Para branches de Correção de algum defeito ou configuração de ferramentas, estas deverão seguir o seguinte padrão de nomenclatura: FIX_[NomeDaCorrecaoOuConfiguracao]

Ao término de uma feature ou correção deverá ser submetido um Pull Request para a branch devel, se a build no TravisCI estiver com o status passing e a análise de saúde do código feita pelo Landscape for maior que 70%. O pull request deve ser examinado e então aceito por outro membro que não tenha trabalhado naquela branch.

Conflitos

Se um pull request causar algum tipo de conflito, deve ser resolvido primeiro pela equipe que desenvolveu o que está causando conflito, e então deve ser refeito o pedido para avaliação do merge.

Integração Contínua

TravisCI vai estar criando Builds e testando nosso projeto e commits do Github, se algum teste falhar ou seu código não seguir a Stylesheet (pep8), o build do seu commit irá falhar e ele não será feito o merge na devel até estar resolvido.

Ambiente de Desenvolvimento

Utilizamos as ferramentas Docker e Docker Compose para evitar erros de compatibilidade e automatizar a criação do ambiente de desenvolvimento. Para os desenvolvedores que não possuem experiência com o desenvolvimento usado o docker e o docker compose, são apresentados alguns comandos abaixo que podem auxiliar aos contribuintes do repositório.

Comandos do Docker:

• docker ps : Lista os containers em execução. Com uso da flag -a, lista todos os containers.
• docker images : Lista imagens.
• docker rm my-conatainer : Remove o container my-container.
• docker rmi my-image : Remove a imagem my-image.

Comandos do Docker Compose:

• docker-compose up : Constrói as imagens, (re)cria, inicia e anexa containers a um serviço. A flag -d executa os cantainers em segundo plano.
• docker-compose down : Termina a execução dos containers, os remove e remove networks e volumes criados por up.
• docker-compose stop : Termina a execução dos containers sem removê-los.
• docker-compose start : Inicia containers existentes para um serviço.
• docker-compose logs : Exibe saída de log dos serviços, a flag -f segue a saída de log.
• docker-compose exec web bash : Executa o comado bash no serviço web.

Labels

Utilizamos labels para a melhorar o entendimento das issues e do que se trata cada uma. Esta classificação permite um planejamento de temas e gerência do conhecimento da equipe.

• Beautify: Algo que sugere embelezamento da página e melhoria de design ou layout.
• Bug: Algum erro, problema ou comportamento inesperado em uma funcionalidade já existente na aplicação.
• Enhancement: Sugestão ou melhoria de uma funcionalidade existente da aplicação
• Javascript: A issue marcada requer conhecimentos de JavaScript.
• Python: A issue marcada requer conhecimentos de Python.
• Question: Uma pergunta relacionada a aplicação, funcionalidade ou do projeto.
• Refactor: Refatoração do código de alguma funcionalidade existente, melhorando performance ou qualidade do código com base nas métricas planejadas.
• Study: A issue trata de um conhecimento não utilizado ainda na plataforma: uma nova ferramenta, biblioteca , framework ou algo relacionado. Exigindo então, estudos aprofundados para descoberta e adaptações a nossa plataforma.
• Test: A issue marcada envolve os testes de código da aplicação.
• Technical Story: A issue marcada é classificada como História Técnica do projeto.
• User Story: A issue marcada é classificada como História de Usuário do projeto.