Ir para o conteúdo

Plano de Gestão e Configuração de Software

Histórico de Versões

Data Versão Descrição Autor(es)
25/08/2020 0.1 Criação do Documento de GCS Daniel Maike, João Pedro, Joberth Rogers
26/08/2020 0.2 Adequação dos Itens de Configuração Daniel Maike, João Pedro, Joberth Rogers
26/08/2020 0.3 Adequação das Políticas e do Uso de Issues Daniel Maike, João Pedro, Joberth Rogers
26/08/2020 1.0 Adequação do Repositório de Documentação e atualização de políticas de commit Daniel Maike

Sumário

1. Introdução

2. Itens de Configuração

3. Políticas

4. Uso de Issues

5. Repositório de Documentação

6. Referências

1. Introdução

  • O presente documento tem como finalidade abordar os procedimentos de gerência e configuração de software a serem seguidos no projeto.

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. Políticas

3.1 Política de Commits

  • Os commits devem ser criados logo em seguida à finalização de um conjunto conexo de alterações, descrevendo-o de forma sucinta e atômica. O formato deve conter o tipo do commit, a descrição e o id da issue no repositório do GitHub. O texto deve descrever o que foi produzido, de forma resumida e em inglês, com o tempo verbal no presente. Como no seguinte formato:

[tipo do commit]: [resumo da alteração] <#id>

  • [tipo do commit] -> Tipo do Commit: feat | fix | docs | style | refactor | test | chore | perf | ci | build | temp
  • [resumo da alteração] -> Resumo da alteração no tempo presente. Não capitalizado. Sem ponto final.
  • <#id> -> Id da issue no repositório do GitHub

Tipos: - feat: para uma nova feature
- fix: para bug fix
- docs: documentação apenas mudanças
- style: mudanças que não afetam o significado do código (espaço em branco, formatação, ponto e vírgula ausente, etc)
- refactor: uma mudança de código que não corrige um bug nem adiciona um recurso
- test: adicionar testes ausentes ou corrigir os existentes
- chore: mudanças no processo de construção ou ferramentas auxiliares e bibliotecas, como geração de documentação
- perf: uma mudança de código que melhora o desempenho
- ci: mudanças em seus arquivos e scripts de configuração de CI
- temp: commit temporário que não será incluído em seu CHANGELOG

  • Exemplo:

feat: create user structure

  • Commits devem ser redigidos no idioma inglês.
  • Devem ser simples e concisos, possuindo títulos curtos.
  • Commits devem descrever o que está sendo alterado, se houver mais de uma alteração (pertinente ao commit) ela deve ser adicionada na descrição do commit.
  • Devem iniciar com letras minúsculas.
  • Devem iniciar com um verbo no presente, informando seu objetivo. Ex: "feat: create new main page"

3.2 Política de Branches


PoliticaBranchs.png


  • O repositório do projeto terá uma branch principal, sendo ela a branch estável, a master.

  • A master será a branch estável do projeto, sendo ela proveniente da develop quando o pull request for aprovado, ao fim de cada release ou quando houver necessidade. Nenhum membro será autorizado a fazer commits diretamente na master.

  • As branches auxiliares são para a resulução de issues do projeto. Cada User Story, Technical Story, HotFix ou BugFix terá sua própria branch, criada a partir da develop, e terá como nomenclatura o seguinte padrão:

feature/US[ID da User Story]-[Nome representativo da US] ou
feature/TS[ID da Technical Story]-[Nome representativo da TS] ou
bugfix/[Nome representativo do Bug Fix] ou
hotfix/[Nome representativo do Hot Fix]

  • As branches develop e master têm papel importante no fluxo seguido. Portanto, nenhuma dessas deve receber um commit diretamente pelo time de desenvolvimento de nenhum User Story, Technical Story, HotFix ou BugFix.

  • Para cada ISSUE uma nova branch deve ser criada com base no último commit da develop, de acordo com o modelo acima.

3.2.1 Conflitos

Se um Pull Request causar algum tipo de conflito, deve ser resolvido primeiro pela equipe que desenvolveu o que está causando conflito, prezando pela integridade e organização do histórico de commits, e então deve ser refeito o pedido para avaliação do merge.

3.3 Política de Aprovação do Código

  • Para a aprovação do código, este deve ser aprovado por ao menos dois membros da equipe de Engenharia de Produto de Software.

4. Uso de Issues

  • As issues serão criadas com o objetivo de mapear as User Story, Technical Story, HotFix ou BugFix, tendo assim um maior controle sobre elas. Com isso, conseguiremos manter o rastro dos commits com suas respectivas issues.

  • As issues serão divididas em labels, para que se possa indicar sua natureza.

  • O padrão do nome das issues terá o seguinte formato:

US<ID incremental> - <Descrição da Issue>
TS<ID incremental> - <Descrição da Issue>
BUGFIX - <Descrição da Issue>
HOTFIX - <Descrição da Issue>

  • Exemplo : "US02 - Criar Termo de Abertura do Projeto (TAP)".

  • E cada descrição de Issue deverá seguir o Issue Template determinado no repositório.

  • Qualquer alteração deve ser solucionada apenas após a criação de uma issue especificando a alteração.

5. Repositório de documentação

O repositório de documentação é encontrado na wiki do projeto. Seu objetivo é armazenar a documentação proveniente do projeto, bem como, as práticas adotadas pela equipe de desenvolvimento.

5.1 Versionamento de documentos

A versão dos documentos deve seguir o versionamento semântico MAJOR.MINOR. Uma alteração que envolva correção ou validação de um documento e que não exija esforço intelictual moderado, deve ser versionado incrementando o dígito MINOR. Para alterações que envolva adição de conteúdo ou correções significativas, deve ser incrementado o dígito MAJOR.

6. Referências