Skip to content

Plano de Gerenciamento de Configuração

Jump to bottom
Jeferson Alves edited this page Sep 28, 2017 · 25 revisions

Histórico de modificações

Data Versão Descrição Autor
08/09/2017 1.0 Adicionando template Jeferson Alves
09/09/2017 1.1 Adicionando uso das ferramentas Jeferson Alves
13/09/2017 1.2 Adicionando políticas do repositório Jeferson Alves
15/09/2017 1.3 Adicionando orientações aos contribuintes Jeferson Alves

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

Obtiva-se com este documento orientar a todos que buscam contribuir com o repositório, apresentando padrões, políticas, ferramentas, instruindo sobre o ambiente de desenvolvimento e qualquer atividade de configuração necessária.

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

No curso do deste projeto serão usadas ferramentas para apoiar no desenvolvimento e configuração. A tabela a seguir relaciona as ferramentas utilizadas e seu respectivo uso.

Ferramenta Logotipo Descrição de Uso
Git [[images/gcs-images/git-logo.png height = 80px]]
Github [[images/gcs-images/github-logo.png height = 80px]]
Docker [[images/gcs-images/docker-logo.png height = 80px]]
Travis CI [[images/gcs-images/travis-logo.png height = 80px]]
Coveralls [[images/gcs-images/coveralls-star-logo.png height = 80px]]
Landscape [[images/gcs-images/landscape-logo.png height = 80px]]
Code Climate [[images/gcs-images/code-climate-logo.png height = 80px]]

4 - Repositório de código

4.1 - Política de Commits

Adota-se para este projeto padrões para o comentário e execução dos commits. O idioma padrão para efetuar commits neste reositório é o inglês. As mensagens devem ser suscintas e expressarem de forma clara e objetiva a ação do commit.

Como exemplo, considere o trabalho da construção de uma tela inicial da aplicação. O commit deverá ser efetuado como segue:

git commit -m "Create new home Screen"

Atente ainda para os seguintes aspectos:

  • O commit deve iniciar com letras maiúsculas.
  • O commit deve iniciar com verbo no infinitivo.

Caso o trabalho tenha sido realizado por mais de um autor. O commit deverá possuir a assinatura das pessoas envolvidas. Nestes casos deve-se utilizar a flag --author ou a opção signed-off-by, de maneira que o trabalho de todos desenvolvedores possa ser refletido por sua contribuição. Como exemplo, veja as instruções:

git commit --author

git commit -s

4.2 - Política de Branches

O repositório possui uma branch master, que possui objetivo de manter a versão estável do projeto. Possui também uma branch para desenvolvimento chamada devel, cujo objetivo é manter-se atualizada. Desta forma nenhum commit deve ser efetuado diretamente nestas branchs. As alterações devem ser criadas inicialmente em branchs de funcionalidades ou de configuração e correção, toda branch de funcionalidade deve ser criada a partir da branch devel.

A imagem a seguir, ilustra como deve ser a organização das branchs e os eventos de criação e merge. Como pode ser visto, após a etapa de desenvolvimento em uma branch de funcionalidade ser concluída, deve ser submetido um pull request antes do merge da mesma. O pull request deve ser conferido e se, estiver em conformidade e a build do Travis CI obter status passing e as métricas atingirem o esperado do planejamento de code review, então o pull request é aceito.

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

Deve-se criar novas branches para trabalho em casos de uso, issues ou histórias de usuário seguindo padrão GitFlow. Estas devem ser galhos da branch devel, e devem seguir a nomenclatura indicada abaixo, redigidas no idioma inglês.

4.3.1 Padrões para Casos de Uso

Branches de caso de uso devem seguir a convenção cammel case e usar o prefixo UC. Como exemplo, suponha o caso de uso para registrar usuário, deverá ser criada uma branch chamada UC_[NomeDoCasoDeUsoEmCamelCase].

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

De forma semelhante ao padrão de casos de uso, o padrão de história de usuário segue a mesma convenção e obedece às mesmas orientações. Porém, deve-se adotar o prefixo us para criação, como segue: US_[NomeDaUSEmCamelCase].

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

Seguindo o padrão para as branchs de correção de algum defeito ou configuração de ferramentas novas, o padrão para nomenclatura será FIX_[NomeDaCorreçãoOuConfiguracao]

4.3.4 Padrões para Issues

Issues devem ser criadas para tarefas que não estejam inclusas nos casos de uso ou histórias de usuário. Caso uma issue não esteja implícita em uma história ou caso de uso e sua complexidade justifique a criação de uma nova branch, esta deve ser criada obedecendo a convenção cammel case com o prefixo ISSUE seguida de seu número. Como exemplo, suponha uma issue cujo objetivo seja corrigir a conexão com o banco de dados e seu número seja 8, uma branch para tratar esta issue teria um nome como: ISSUE_08_FixConnectionWithDatabase.

4.4 - Política de aprovação

A aprovação dos commits serão feitos de forma automatizada. Os serviços do Travis CI, Code Climate e Landscape serão configurados nas branchs de desevolvimento. Caso falhe algum teste unitário, caso a folha de estilo não seja seguida, a build não obtenha o status desejado ou as métricas não se adequem a nosso Plano de medições, o commit não será aceito. A aprovação de pull requests depende, além da aprovação do Travis CI e das ferramentas de coleta de métricas, da aprovação de um desenvolvedor da equipe diferente daquele que o submeteu.

4.5 - Versionamento de código

Usa-se para versionamento de código neste repositório o padrão definido no Semantic Versioning 2.0.0. Representando a versão com os dígitos MAJOR.MENOR.PATCH. Onde o dígito MAJOR deve ser incrementado quando alterações incompatíveis da API são realizadas, o dígito MENOR quando são adicionadas funcionalidades de forma compatível com versões anteriores e o PATCH quando correções de bugs compatíveis com versões anteriores são realizadas.

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. Este repositório segue especificações semelhantes ao repositório de código. Os commits devem seguir o mesmo padrão. Porém, os documentos devem ser mantidos na branch master e não há instruções a respeito da criações de novas branches.

5.1 - Versionamento de documentos

A versão dos documentos deve seguir a semântica 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 - Monitoramento e controle

Todas as normas e padrões descritos neste documento são monitorados pela equipe de gerenciamento do projeto. A equipe de gerenciamento é reponsável pela organização e ordem do repositório. Sendo assim, possui o poder de veto e exclusão de itens fora das especificações. A equipe também se compromente a ajudar e orientar a todos que desejem contribuir. Dúvidas ou sugestões, devem ser encaminhada aos gestores do projeto.

7 - Referências

Quero Cultura

Sobre

Release 2

Coleta de Métricas

Sprint 0

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6

Sprint 7

Sprint 8

Sprint 9

Release 1

Gerência de Projeto

Planos de Gerenciamento

Desenvolvimento de Software

Clone this wiki locally