Plano de Gerenciamento de Configuração

Histórico de Revisão

Data	Versão	Descrição	Autor(es)
26/03/2017	1.0	Iniciação	Lucas Mattioli
29/03/2017	1.1	Code Climate	Lucas Mattioli
17/04/2017	1.2	Deploy	Lucas Mattioli
17/04/2017	1.3	Instalação do Vagrant	Victor Hugo

Sumário

1. Introdução
2. Virtualização de Ambiente
   2.1. Instalação do Vagrant
3. Versionamento
   3.1. Política de Branches e Integração Contínua
   3.2. Commits
4. Análise Estática de Código
5. Deployment Automático

1. Introdução

Este plano tem como objetivo especificar como o gerenciamento de configuração e mudança de software no projeto Escola X acontecerá. Basicamente, serão especificados os métodos de virtualização/padronização de ambiente, a metodologia de versionamento e o método de integração contínua.

2. Virtualização de Ambiente

Com o objetivo de padronizar o ambiente de todos os desenvolvedores do projeto, a prática de virtualização de ambiente será utilizada. Para tal feito, as duas ferramentas utilizadas serão: Vagrant 1.9.3 e VirtualBox 5.1.18, este que servirá como container virtual para o Vagrant.

A configuração da virtualização é feita pelo arquivo Vagrantfile na raiz do projeto. Quando o repositório do projeto for clonado, o simples comando `vagrant up` criará uma box (ambiente virtual) contendo a distro Ubuntu 14.04; dentro dessa box serão instaladas, com o auxílio de scripts, as tecnologias necessárias para desenvolvimento: Ruby 2.3.1 e Rails 5.0.1.

2.1 Instalação do Vagrant

Agora serão mostrados os comandos necessários para a instalação do Vagrant:

Observação: os comandos abaixo desde baixar o repositório até a instalação desta ferramenta, foram voltados para usuários que utilizam o sistema operacional Linux.

1. O primeiro passo para a instalação do vagrant é baixar o repositório deste projeto, basta clicar nesse link: Projeto Escola-X.

2. Após entrar no repositório deste projeto, é necessário clonar o repositório. A imagem a seguir mostrará onde fica localizado o link para clonar o repositório.

Clicando como mostrado na imagem acima, basta clicar e irá aparecer um link ".git", basta copiar esse link, abrir o terminal e da o comando "git clone" na pasta em que desejar armazenar este projeto.

3. Agora é necessário baixar o software "VirtualBox" que será utilizado junto com o vagrant. Este software pode ser baixado gratuitamente no seguinte link: VirtualBox. Selecione a sua versão de distribuição linux e baixe.

4. Para baixar o vagrant é necessário que seja realizado o download em seu site oficial. Clicando no seguinte link, é mais rápido para encontrar as versões disponíveis deste software: .

5. Após realizar os passos anteriores e com o projeto devidamente clonado, entre na pasta do projeto com o comando "cd nomeDaPasta/2017.1-Escola-X".

6. O próximo passo, ainda no terminal, é da o comando "vagrant up". Esse comando irá ligar a box baseada no arquivo "VagrantFile" que está na raiz do repositório. A imagem a seguir irá mostrar o que deve acontecer quando dado o comando "vagrant up" pela primeira vez.

Após realizadas todas as etapas de instalação do vagrant, o terminal deve mostrar o seguinte relatório :

Com isso, já é possível utilizar o ambiente padronizado para este projeto, com o ruby na versão 2.3.1 e com o framework rails na versão 5.0.1.

Os seguintes comandos são elementares para se utilizar os recursos do vagrant juntamente com a virtualbox. Todos devem ser utilizados no terminal na pasta do projeto.

• vagrant up - liga uma box (Utilizar toda vez que começar a programar no projeto);

• vagrant ssh - se conecta a maquina virtual;

• exit - sai da máquina virtual;

• vagrant halt - desliga a maquina virtual (Utilizar toda vez que parar de programar no projeto).

3. Versionamento

A ferramenta Git será utilizada para versionamento do código, aliada ao GitHub, que servirá como repositório remoto.

3.1. Política de Branches e Integração Contínua

A política de branches utilizada será a master-slave, contando com o auxílio da ferramenta de integração contínua Travis CI. Na estratégia master-slave, uma branch é escolhida como mestre (development no nosso caso) e as outras são ditas escravas dessa branch.

Quando alguma modificação de código precisar ser feita, o desenvolvedor criará uma branch X (escrava) a partir da branch mestre; após a modificação ser feita, o desenvolvedor realiza um commit na branch X e a ferramenta Travis CI executará todos os testes da aplicação considerando essa nova modificação feita. Se todos os testes passarem, a branch X é automaticamente fundida pelo Travis CI com a branch mestre. Caso existam conflitos na fusão de branches, o desenvolvedor deve resolver o conflito para que, então, a fusão possa ser feita.

De tempos em tempos, a branch development será fundida pelos responsáveis pelo repositório com a branch master, após revisões das alterações feitas. No caso, os únicos que têm acesso à branch master são os ditos responsáveis. Em caso de complicações na aplicação, a branch master será utilizada como a válvula de escape, já que, teoricamente, ela só receberá modificações fortemente revisadas.

3.2. Commits

Os commits devem ser feitos utilizando a língua inglesa, com o objetivo principal de internacionalização do código. Devem, também, conter mensagens sucintas e claras do que a modificação feita faz. As modificações feitas devem seguir a folha de estilo adotada pelo projeto.

4. Análise Estática de Código

A ferramenta Code Climate será utilizada para realizar a análise estática de código. O Code Climate mantém uma nota, que varia de 0.0 até 4.0, que representa a qualidade do código do projeto. Essa nota é baseada em atributos do código, como: complexidade, duplicação, segurança e estilo. Além disso, uma lista de pendências a serem melhoradas é mantida pela ferramenta, a qual é atualizada a cada commit feito. Com base nessa nota e na lista de pendências, a equipe tomará medidas para resolver tais situações. Para verificar a nota do código do projeto, basta checar a badge na descrição do repositório.

5. Deployment Automático

Toda alteração feita na master (via pull requests) é colocada automaticamente em um servidor de homologação, com o auxílio da plataforma Heroku. Com as revisões dos pull requests feitas pela equipe de GPP e o auxílio da ferramenta de integração contínua Travis CI, as builds colocadas em homologação estarão, muito provavelmente, estáveis. Link para o servidor de homologação.