Plano de Gerenciamento de Configuração
| 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 contribuidores | Jeferson Alves |
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.
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.
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]] |
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
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.
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.
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].
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].
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]
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.
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 nossas a nossas métricas, 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.
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.
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.
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.
-
PMI. Um guia do conhecimento em gerenciamento de projetos. Guia PMBOK® 5a. ed. - EUA: Project Management Institute, 2013
-
PlataformaJogosUnB. Plano de Gerenciamento de Configuração de Software. Disponível em <https://github.com/fga-gpp-mds/2017.1-PlataformaJogosUnB/wiki/Plano-de-Gerenciamento-de-Configura%C3%A7%C3%A3o-de-Software>
- Visão Geral
- Políticas do Repositório
- Licença
- Copyleft
- Notas sobre a Release
- Contatos
- Atas de Reunião
- Apresentação R1
- Acesse a plataforma
- Link Alternativo
- Post mortem