Plano de gerenciamento de configuração de software

Histórico de Revisão

Data	Versão	Modificação	Autor
23/03/2017	0.0.1	Criação do documento	Fábio Teixeira
23/03/2017	0.0.2	Introdução e Gerenciamento de Configuração	Fábio Teixeira
25/03/2017	0.0.3	Git e Github	Phelipe Wener
26/03/2017	0.1.0	Heroku, Travis e box vagrant	Fábio Teixeira

---

Sumário

1. Introdução
2. Gerenciamento de Configuração de Software
   1. Organização, Responsabilidades e Interfaces
   2. Ambiente e Infra-estrutura
3. Git e Github
   1. Repositório do projeto
   2. Política de branch
   3. Commits
   4. Política de aprovação de código
4. Heroku
5. Travis
6. Box vagrant

1. Introdução

Este documento visa detalhar a configuração necessária para as tecnologias que serão utilizadas durante o desenvolvimento do projeto.

2. Gerenciamento de Configuração de Software

2.1. Organização, Responsabilidades e Interfaces

O time de GPP será responsável por manter o ambiente de desenvolvimento de todos os membros do time.

2.2. Ambiente e Infra-estrutura

Nosso ambiente de desenvolvimento será utilizado virtualização para manter um ambiente conciso e uniforme entre todos os membros.

Uma máquina virtual será criada por GPP para distribuir entre todos os membros um ambiente pronto para uso e de fácil gerenciamento. Essa box será armazenada em uma nuvem de de boxes vagrant, a atlas.hashicorp.com.

O nosso ambiente de homologação será lançado na plataforma heroku.

3. Git e Github

3.1. Repositório do projeto

Será utilizado para repositório remoto o github, junto com a wiki do projeto.

3.2. Política de branch

Para cada evolução do código, deverá ser criado uma branch cujo nome descreva a intenção da branch, portanto devem ser usados nomes como: bookImplementing, bookRefactoring ou algo que descreva o que está sendo alterado e o que está sendo feito. Ao final do desenvolvimento da Branch, com as devidas modificações, deve-se realizar um "pull request" para a branch homolog. Assim, quando o Travis sinalizar que a build da branch de homologacao estiver passando, então o Travis irá automaticamente enviar a última build da branch homolog para o Heroku que subirá em homologação a aplicação, que após devidamente homologada terá suas adições inseridas na branch master.

3.3. Commits

Para realização de commits é importante que se tenha um author, em caso de um ou mais participantes, deve-se usar a flag --author para que seja descrito todos colaboradores envolvidos.

Toda mensagem de commit deve ser em inglês, tal que seja possível a compreensão do projeto em vários países.

3.4. Política de aprovação de código

Para um "pull request" ser aceito, deve-se atender aos seguintes critérios:

• Coesão com a folha de estilo
• Nenhum teste em falha
• Testes da evolução implementados
• Boas práticas em débito

Caso algum destes tópicos estejam falhando, um gerente de projeto irá comentar os pontos a aperfeiçoar.

Pull request - É um recurso do github que permite aos outros visualizarem as alterações feitas em determinada branch, para que se possa compreender as modificações, bem como discutir melhoras. Os "pull requests" deverão ser direcionado a branch homolog para que o Travis suba as adições em homologação.

4. Heroku

Para deploy em um ambiente de homologação, será utilizado o serviço Heroku. Este deploy será feito de forma automática pelo Travis, onde sempre que algo novo entrar na branch homolog e a build dessa branch passar.

5. Travis

Para teste contínuo da aplicação será utilizado o travis-ci, que conta com uma ferramenta em nuvem para acusar qualquer falha em commit. O Travis irá manter um tracking dos "pull requests", de forma que sempre que PR um for aberto, possa se ter a garantia que de este PR não irá "quebrar" o ambiente de homologação.

6. Box vagrant

Como dito no tópico Ambiente e Infra-estrutura será utilizada uma box vagrant para o ambiente de desenvolvimento. Os passos necessários para a sua utilização estão descritos no nosso documento Configuração Ambiente Dev