Plano de Gerenciamento de Configuração - Desenho-Grupo2/PlanUp GitHub Wiki

Histórico de modificações

Data Versão Descrição Autor
06/05/2018 1.0 Adicionando template Marlon Mendes

Sumário

  1. Introdução
  2. Itens de configuração
  3. Ferramentas
  4. Repositório de código
  5. Repositório de documentação
  6. Monitoramento e controle
  7. Referências

1 - Introdução

O objetivo deste plano é orientar contribuidores sobre como contribuir com o projeto, considerando todas as convenções e padrões internos a equipe bem como as ferramentas utilizadas no processo de desenvolvimento.

2 - Itens de configuração

Serão tratados como itens de configuração para este projeto o código e a documentação que o acompanha. Descrimina-se abaixo os itens de configuração para os quais faremos a manutenção e gerenciamento.

  • Documento: Arquivo de texto contendo planejamentos, descrição do produto e projeto, relatos de reunião ou do fluxo de projeto.
  • Código: Artefato composto por um conjunto de arquivos de texto, contendo código de uma ou mais linguagens de programação ou marcação.

3 - Ferramentas

Ferramenta Descrição de Uso
Git Ferramenta utilizada para controle de versões e gerenciamento do código produzido e da própria documentação inerente ao código
Github Responsável pela hospedagem do código fonte, documentações, manuntenção de artefatos de requisitos e todos os outros artefatos do projeto
Docker Utilizado para automatizar a configuração do ambiente de desenvolvimento, garantir que os desenvolvedores trabalhem em ambientes padronizados e eliminar problemas de compatibilidade
Travis CI Ferramenta para auxiliar na integração contínua no repositório do GitHub
Code Climate Ferramenta para verificação da qualidade estática de código
Telegram Ferramenta de comunicação interna da equipe e monitoramento do status do repositório (builds, commits, issues etc)
Astah Criação de diagramas utilizando UML, como Diagrama de Classe, por exemplo.

4 - Repositório de código

4.1 - Política de Commits

As mensagens dos commits devem ser escritas de forma curta e objetiva, no idioma inglês. A mensagem deve explicar brevemente o conteúdo do commit.

4.2 - Política de Branches

4.3 - Padrões para criação e uso das branches

O nome de todas as branches devem ser escritas em letras minúsculas e em snake_case.

Branch Descrição
master Código que está em produção.
development Código estável, e de desenvolvimento. Sua upstream é a master. Desenvolvimento de novas funcionalidades devem partir da branch development
feature_* Branches que começam com o nome feature_ são exclusivas para desenvolvimento de novas features. São branches criadas a partir da development
hotfix_* Branches que começam com o nome hotfix_ são exclusivas para correção de bugs encontrados na master.

4.3.1 Padrões para Casos de Uso

Nome da branch: feature_ + nome_do_caso_de_uso

Exemplo: feature_create_user

4.3.2 Padrões para Histórias de Usuário

Nome da branch: feature_ + nome_da_historia

Exemplo: feature_delete_user

4.3.3 Padrões para Correções e configuração

4.3.4 Padrões para Issues

Issues devem ser escritas em português.

Issue Descrição
Histórias de usuário USXX - Descrição Exemplo: US06 - Aluno gerenciar suas disciplinas
Demtórias issues As demais issues não possuem um tamplte pois podem ser utilizadas para fins muito específicos, como por exemplo ajustar um diagrama, devem entretanto ser escritas em português, serem curtas e objetivas

4.4 - Política de aprovação

Issue Descrição
master A única forma de modificar a master é por meio de pull requests. Estes pull requests devem ser revisados e aprovados por pelo menos dois (2) desenvolvedores para que o pull requests seja aceito. Além disso, a build deve ser sucesso na integração contínua.
Demais branches Aprovação automática: basta ser sucesso nos ambientes de integração contínua.

4.5 - Versionamento de código

Apenas este repositório no Github.

5 - Repositório de documentação

5.1 - Versionamento de documentos

Apenas o repositório da wiki no Github.

6 - Monitoramento e controle

O monitoramento do repositório princial é majoritariamente monitorado automáticamente através da Integração Contínua. A integração contínua também é responsável por notificar via Telegram e email caso alguma build não tenha sucesso. Além disso, o código também é constantemente monitorado através dos pull requests. Em geral o controle é feito manualmente pela equipe de desenvolvimento, assim como o monitoramento e controle de todos os documentos.

7 - Referências