Plano de Gerenciamento de Configuração

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 contribuidores	Jeferson Alves

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 documetação que o acompanha. Descrimina-se abaixo os itens de configuração para os quais fará-se 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]]

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 siggned-off-by, de maneira que o trabalho de todos desenvolvedores possa ser reflletido 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, 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, 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. Estas devem ser galhos da branch devel, e devem seguir a nomeclatura 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_RegisterUser.

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_RegisterUser.

4.3.3 - Padrões para Issues

Issues devem ser criadas para tarefas que 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 commities serão feitos de forma automatizada. Os serviços do Travis CI serão configurados nas branchs de desevolvimento. Caso falhe algum teste unitário, caso a folha de estilo não seja seguida ou a build não obtenha o status desejado, o commit não será aceito. A aprovação de pull requests depende, além da aprovação do Travis CI, da aprovação de um desenvolvedor da equipe diferente daquele que o submeteu.

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.3 - 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.