Urutau

Fonte: Wikiversidade
Estudantes: Izabela Cristina e Tainara Santos

Repositório: https://github.com/tainarareis/Urutau/tree/entrega2

Introdução[editar | editar código-fonte]

Visão Geral[editar | editar código-fonte]

A norma IEEE 14764 descreve a Gerência de Configuração como um elemento crítico na manutenção do processo. Seus procedimentos devem prover verificação, validação e auditar cada passo necessário para identificar, autorizar, implementar e, por fim, entregar o produto de software (SWEBOK, pg. 59; 2004).

Trata-se da disciplina responsável por prover "o processo de ciclo de vida do suporte ao software que beneficia atividades de gerenciamento, desenvolvimento, manutenção, qualidade, bem como beneficia aos clientes e usuários finais do produto." (SWEBOK, pg. 61; 2004). Pode-se utilizar o conceito de Gerência de Configuração a quaisquer itens que possam ser controlados, sejam hardware ou software, durante os ciclos de desenvolvimento e manutenção de software.

Partindo destes conceitos explicitados, a Gerência de Configuração de Software se faz necessária em quaisquer produtos de software a exemplo do Urutau.

Propósito[editar | editar código-fonte]

O presente documento tem por finalidade apresentar o plano e execução do gerenciamento de configuração e mudanças do projeto Urutau. No contexto atual, este projeto não possui processo de GCS

Problema[editar | editar código-fonte]

Atualmente, o Urutau apresenta os seguintes problemas:

- Não é possível saber qual é a versão estável do sistema;

- Não são documentadas as versões e suas respectivas localizações do código-fonte;

- Não há controle das modificações que são realizadas e suas motivações;

- Os itens de configuração não são listados ou identificados;

- Ausência de processo de auditoria.

Escopo[editar | editar código-fonte]

Serão atendidas as seguintes demandas para o projeto Urutau:

  1. Implantação de integração contínua;
  2. Implantação automática de integração contínua;
  3. Deploy automatizado;
  4. Configuração de ambiente virtual de desenvolvimento.

Definições, Acrônimos e Abreviações[editar | editar código-fonte]

Termo Significado
Baseline É um marco a partir da entrega de um ou mais itens de configuração
Build de Software "É a atividade de combinar versões corretas de itens de configuração de software, utilizando dados de configuração apropriados, em programas executáveis a serem entregues ao cliente ou a outro destinatário, como, por exemplo, a atividade de teste." (SWEBOK, tópico 6-11; 2004).
Integração Contínua "Realizar de forma automatizada builds, ou cópias parciais ou totais de softwares que estão em desenvolvimento, realizando testes unitários, testes de integração, testes funcionais, análise estática de código e outras atividades que a ferramenta em questão possa executar de forma automática para garantir a qualidade do produto." (TARGETTRUST, 2016).
GCS Gerência de Configuração de Software
Urutau Software tratado por este documento. Trata-se de uma ferramenta de gerenciamento de requisitos de software. Disponível em: https://github.com/Modesteam/Urutau

Apresentação do projeto[editar | editar código-fonte]

Urutau é uma ferramenta de gerência de requisitos durante o processo de desenvolvimento de software.Sua proposta é atender diversas formas de documentação baseado em interface amigável e simples. Além das funcionalidades básicas de uma ferramenta de requisitos, no futuro o Urutau poderá suportar plugins proporcionando customização da ferramenta. É utilizado o framework MVC Vraptor4, com design baseado em Bootstrap, ambos Open Source. O projeto se originou na disciplina Técnicas de Programação ministrada na Universidade de Brasília em 2015.

Papéis e Responsabilidades[editar | editar código-fonte]

Papel Responsabilidade Responsável
Gestor de configuração do projeto Acompanha as alterações dos itens de configuração Tainara
Gestor de ferramentas de gerência de configuração Realiza a manutenção da infraestrutura, isto é, a plataforma operacional e ferramentas utilizadas no processo de GCS) Izabela e Tainara
Gestor de configuração de software Aprova e gerencia as atividades de GCS Izabela
Auditor de configuração de software Realiza a auditoria de configuração no projeto Izabela e Tainara
Desenvolvedor Produz os itens de configuração que são gerenciados, no caso, o código-fonte do Urutau Phelipe, Rafael, Ricardo e Tainara

Ferramentas, Ambiente e Infra-estrutura[editar | editar código-fonte]

Ferramenta Versão Descrição Disponibilização
Vagrant 1.8.1 Possibilita criar e configurar ambientes de desenvolvimento leves, reprodutíveis e portáteis. https://www.vagrantup.com/downloads.html
VirtualBox 5.0.2 Possibilita a criaçaõ de máquinas virtuais. https://www.virtualbox.org/
Travis Provê serviços de integração contínua https://travis-ci.com/
Puppet Ferramenta de GCS para a escrita de "receitas" sobre como o sistema deve ser configurado. Isto ocorre com relação a dependências, pacotes que devem ser instalados, os serviços que devem ser executados, ou arquivos que devem ser escritos https://puppet.com/

Cronograma[editar | editar código-fonte]

Release Milestone Sprint Período Atividade Status
1 Planejamento 1 20 a 26 de abril Redigir plano de GCS Realizado
2 27 de abril a 3 de maio Selecionar ferramentas a serem utilizadas Realizado
27 de abril Ponto de controle 1 Realizado
2 Máquina Virtual 3 4 a 10 de maio Estudar a ferramenta Vagrant Realizado
4 11 a 17 de maio Estudar as ferramentas Puppet e Chef Realizado
Instanciar máquina virtual (Vagrant + Puppet) Realizado
3 Integração Contínua 5 18 a 24 de maio Estudar as ferramentas Travis e Jenkins Realizado
6 25 a 31 de maio Implementar integração contínua (Travis) Realizado
1 de junho Ponto de controle 2 Realizado
4 Deploy 7 2 a 8 de junho Estudar as ferramentas de deploy automático Realizado
8 9 a 15 de junho Automação do deploy Realizado
22 de junho Entrega final Realizado

Instalação atualmente[editar | editar código-fonte]

As instruções para configuração do software Urutau constam na wiki do projeto disponível no seguinte link: https://github.com/Modesteam/Urutau/wiki/Guia-de-desenvolvimento

Vagrant e Virtualbox[editar | editar código-fonte]

O vagrant é o utilitário de linha de comando para gerenciamento do ciclo de vida de máquinas virtuais. Trata-se de uma ferramenta para a construção completa de ambientes de desenvolvimento, restrito à uma máquina virtual. O principal benefício está em reduzir o tempo de configuração do ambiente de desenvolvimento, aumentando assim o tempo dedicado ao desenvolvimento.

Abaixo, está descrito o que o Vagrant realiza segundo o livro Vagrant: Up and Running de Mitchell Hashimoto:

• Cria uma máquina virtual com base em um sistema operacional da escolha do usuário;

• Modifica as propriedades físicas desta máquina virtual (por exemplo, RAM, número de Processadores, etc);

• Estabelece interfaces de rede para que se possa acessar a máquina virtual a partir do próprio computador, um outro dispositivo na mesma rede, ou até mesmo de outra máquina virtual;

• Define as pastas compartilhadas para que se possa continuar a edição de arquivos na própria máquina e ter essas modificações espelhadas sobre a máquina guest.

• Realiza o bootmdaáquina virtual para que ele asseja executada;

• Define o nome da máquina (hostname), uma vez que uma grande quantidade de software utiliza o nome da máquina para ser corretamente configurados;

• Provê softwares para a máquina através de um shell script ou softwares de gerenciamento de configuração como o Chef, Puppet

Resultados[editar | editar código-fonte]

No contexto do presente trabalho foram resultados:

Instalações necessárias[editar | editar código-fonte]

$ dpkg -i vagrant_1.8.4_x86_64.deb
$ dpkg -i virtualbox-5.0_5.0.22-108108-Ubuntu-precise_i386.deb

Primeiros passos[editar | editar código-fonte]

1. Crie a máquina virtual que roda o Ubuntu 12.04 LTS 64-bit.

$  vagrant init hashicorp/precise64

2. O vagrant up instala cada dependência que o seu projeto precisa e configura cada pasta sincronizada.

$ vagrant up

Após esses dois comando uma máquina virtual Ubuntu 12.04 LTS de 64 bits isolada, com todos os recursos, será executado em segundo plano.

3. Pode ser solicitado que se faça o login numa conta do servidor HashiCorp's Atlas. Registre-se aqui: https://atlas.hashicorp.com/account/new. E então faça o login:

$ vagrant login

Principais comandos[editar | editar código-fonte]

  • Redirecionar para um console SSH dentro da máquina virtual: você pode fazer qualquer coisa que gostaria aqui, como a instalação de software, modificação de arquivos, ou mesmo remover todo o sistema de arquivos (HASHIMOTO, 2013).
$ vagrant ssh
  • Se algo der errado, ou se só quiser recomeçar a partir de uma máquina limpa, utilize o vagrant destroy que remove todos os traços do ambiente de desenvolvimento (HASHIMOTO, 2013).
$ vagrant destroy

É comum que o desenvolvedor realize alterações no Vagrantfile. Depois de fazer quaisquer modificações, um reload deve ser chamado. (HASHIMOTO, 2013).

$ vagrant reload

Vagrantfile[editar | editar código-fonte]

  • A principal função do Vagrantfile é descrever o tipo de máquina necessário para um projeto, e como configurar e disposição dessas máquinas;
  • O Vagrant roda um Vagrantfile por projeto, e o Vagrantfile deve ser versionado igualmente a outros arquivos. Isso permite que outros desenvolvedores envolvidos no projeto possam verificar o código, executar o " vagrant up", e utilizar a máquina virtual configurada;
  • A sintaxe de Vagrantfile é Ruby, mas o conhecimento da linguagem de programação Ruby não é necessário para fazer as modificações, uma vez que o único conhecimento necessário é sobre atribuição de variável, em sua maioria simples.
  • Documentação: https://www.vagrantup.com/docs/vagrantfile/
# -*- mode: ruby -*-
# vi: set ft=ruby :

# Pode-se definir a versão do vagrant (porém é possível usar duas versões simultaneamente.
Vagrant.configure(2) do |config|
	# Cria uma máquina virtual usando a imagem do Ubuntu 64 bits
    config.vm.box = "hashicorp/precise64"

	# Define uma máquina virtual chamada "web"
	config.vm.define :my_virtualbox do |web_config|
        # Permite acessar o endereço "localhost:8080" para acessar a porta 80 na
        "guest machine"
        config.vm.network "forwarded_port", guest: 80, host: 8080
    
        # Cria uma rede privada que permite apenas acesso do host à maquina
        # Utilizando um ip específico.
        web_config.vm.network "private_network", ip: "192.168.50.10"
    end

    # Checa atualizações
    # `vagrant box outdated` é equivalente porém é recomendável checar automaticamente.
    config.vm.box_check_update = true

    #Configura o puppet como "provisioner"
    config.vm.provision :puppet do |puppet|
        puppet.manifests_path = "puppet/manifests"
        puppet.module_path = "puppet/modules"
        puppet.manifest_file = "default.pp"
    end
end

Puppet[editar | editar código-fonte]

A automatização da instalação de pacotes foi realizada através do provisionador Puppet, os comandos deste provisionador são escritos em arquivos chamados manifests, com uma linguagem baseada no Ruby. O manifest utilizado no projeto está exemplificado na sessão Resultados.

Motivação[editar | editar código-fonte]

As principais motivações para a escolha do Puppet foram:

  • Alta popularidade, portanto, muita informação disponível;
  • Módulos prontos mantidos pela puppetlabs;
  • Curva de aprendizado média;

Passo-a-passo[editar | editar código-fonte]

No manifest principal, exemplificado na subsessão de Resultados, é executado um update do sistema e são instaladas as seguintes dependências: Maven, Tomcat e JDK, de acordo com o Guia de Desenvolvimento do Urutau, além do git, usado para versionamento do código do projeto.

Em seguida, é configurado o banco de dados utilizado no Urutau, o PostgreSQL. Para a instalação do mesmo, foi utilizado o módulo fornecido pela puppetlabs, que mantém o puppet, para fazer a instalação deste módulo basta executar o seguinte comando:

puppet module install puppetlabs-postgresql

Com o módulo disponível, criou-se o banco de dados, o usuário e foi configurada a permissão para o banco criado, também de acordo com o Guia de Desenvolvimento do Urutau.

Resultados[editar | editar código-fonte]

#Executa o update no sistema
exec { "apt_update":
  command => "apt-get update",
  path    => "/usr/bin",
}

#Instalacao das dependencias
package { [
  'openjdk-7-jdk',
  'git',
  'tomcat7',
  'maven',
]:
  ensure => present,
  require => Exec["apt_update"],
}

#Configuracao do banco de dados

class { 'postgresql::server': }

postgresql::server::db { 'urutau' :
    user => 'urutau',
    password => postgresql_password('urutau', 'urutau'),

}

postgresql::server::role { 'urutau' :
    password_hash => postgresql_password('urutau', 'urutau'),

}

postgresql::server::database_grant { 'permission' :
    privilege => 'ALL',
    db => 'urutau',
    role => 'urutau',
}

Empacotamento Debian[editar | editar código-fonte]

Também foi realizado o empacotamento debian através do arquivo .war gerado a partir da branch mais estável do projeto. Para isso, os seguintes comandos foram executados:

#Instalação dos pacotes necessários para construção do .deb
sudo apt-get install dh-make debhelper devscripts fakeroot

Foi criado o diretório "urutau-0.1", e o arquivo "Urutau.war" foi copiado para o novo diretório criado. Após estes passos, o seguinte comando foi executado para gerar os arquivos "esqueleto" necessários para a construção do pacote.

#Cria os arquivos "esqueleto" necessários para o empacotamento
dh_make -s --indep --createorig

Com o comando acima é criada a pasta debian com alguns arquivos. Em sequência, foi apagado o conteúdo desnecessário do arquivo debain/rules, visto que está sendo usando um arquivo .war pré-construído.

#Apaga conteúdo desnecessário do arquivo rules
grep -v makefile debian/rules > debian/rules.temp
mv debian/rules.temp debian/rules

O arquivo debian/rules ficou da seguinte forma:

#!/usr/bin/make -f

# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1

%:
	dh $@

No arquivo debian/control foram setadas as dependências do projeto, isto é, o Maven, JDK e PostgreSQL, além de algumas configurações como mostrado no resultado a seguir:

Source: urutau
Section: unknown
Priority: optional
Maintainer: Izabela Cristina <cizabelacristina@gmail.com>
Build-Depends: debhelper (>= 8.0.0)
Standards-Version: 3.9.4

Package: urutau
Architecture: all
Depends: ${misc:Depends}, openjdk-7-jdk, postgresql, tomcat7, maven
Description: Software requirements management tool
 Urutau is a requirements management tool, with the proposal to meet various forms of documentation in a friendly and simple interface.

Por fim, no Changelog são registradas as mudanças, com responsável, data e horário.

urutau (0.1-1) unstable; urgency=low

  * Initial release (Closes: #nnnn)  <nnnn is the bug number of your ITP>

 -- Izabela Cristina <cizabelacardoso@gmail.com>  Mon, 04 Jul 2016 21:59:42 -0300

Para a construção do pacote, foi executado o seguinte comando

debuild -us -uc

Assim, o pacote urutau_0.1-1_all.deb foi gerado com sucesso.

TravisCI[editar | editar código-fonte]

O Travis CI proporciona um ambiente de build padrão e um conjunto padrão de etapas para cada linguagem de programação. É possível personalizar qualquer passo neste processo através do arquivo .travis.yml. O Travis CI usa o arquivo .travis.yml na raiz do repositório para tomar conhecimento sobre o projeto e como a build deve ser executada. O travis.yml pode ser escrito de forma minimalista ou detalhado. Alguns exemplos de que tipo de informação o arquivo .travis.yml pode ter:

  • A linguagem de programação o projeto usa;
  • Os comandos ou scripts que devem ser executados antes de cada compilação (por exemplo, para instalar ou clonar as dependências do projeto);
  • O comando usado para executar o conjunto de testes.

Motivação[editar | editar código-fonte]

As principais motivações para a escolha do Travis CI foram:

  • Ele é gratuito para repositórios públicos;
  • Ser um serviço de Integração Contínua na nuvem que pode ser conectado a repositórios no GitHub;
  • Notifica o usuário (por e-mail) sobre resultados da build;
  • Vasta documentação;
  • Rápida curva de aprendizado.

Passo-a-passo[editar | editar código-fonte]

  1. Registre-se no Travis CI usando a conta do GitHub para que o Travis CI se sincronize com seus repositórios;
  2. Acesse a página https://travis-ci.org/profile/;
  3. Selecione o repositório em que deseja realizar a build:
    Seleção do repositório
    Seleção do repositório
  4. Adicione um arquivo .travis.yml ao repositório. Este arquivo contém as informações sobre como realizar a build. É preciso commitar e dar push para que o Travis CI realize o build;
# Definição da linguagem
language: java

# Cada comando no script é como um comando no terminal.
script: mvn clean install #exclui o diretório de destino e recria todos os frascos no local.

# Definição de variáveis de ambiente
env:
  global:
    - JAVA_HOME=/usr/lib/jvm/java-8-oracle

# É possível testar múltiplas JDKs
jdk:
  - oraclejdk8
  - oraclejdk7

# Uma vez que é desnecessário instalar as dependências
# duas vezes, o comando abaixo pula a primeira instalação.
# O Maven irá baixar as dependências através do 'script' de qualquer maneira.
install: /bin/true

5. Acesse https://travis-ci.org/ para acompanhar o status do build.

Build Status
Build Status

Customização[editar | editar código-fonte]

Neste projeto foi utilizada a documentação do Travis CI direcionada a tópicos específicos para projetos em Java (https://docs.travis-ci.com/user/languages/java)

Deploy através do Travis[editar | editar código-fonte]

O Travis CI pode realizar o deploy automaticamente o aplicativo Heroku após uma build bem-sucedida.

Para usar a configuração padrão, é preciso adicionar uma a chave criptografada do Heroku no arquivo .travis.yml. Abaixo o passo-a-passo:

1. Instalar o TravisCI

$ gem install travis

2. Rode o comando para gerar a chave de segurança do git:

$ travis encrypt $(heroku auth:token) --add deploy.api_key

3. No .travis.yml serão geradas automaticamente as linhas ao final do arquivo:

deploy:
  api_key:
    secure: K53yiEGH+8BXGTA1J8hZzb7U1fhinTiVt3Pi+ebRTHHq2nwzKd3/c1fB6szC64xTmRW3kFDjndWIBhTUopyl+lB+jowp3QA7GngTZDAQxT0wByMiXNd4yB4b0YKMuCzqVV/dz+UgONtV2Udq2F8if2HSAtHxn2VSFitBcDk2hLuWy3KpXF1x3+5sqgYGOVcVtjB5o5B8qKDa+hGzy0ncjFRgYygMkRd32tzSieHWJcyCAeQutfyZTa5wZqXhIRXn3T4EduJi1gJA1eS6BzycjduyagXOzK7bh0/Zx6XlsUkfvoqG/u71esQSk4TwGOsR35EFU/UxIVKUI+Teqqveo8A6qxOmtj2qcfg7VK/34maRUOzK+mTVTmlpQqPmhjgXpdYA9maTIx1wXm33r4WFybR1BC7DtnSoSus19MATiLxMX/hqpLlk5Ik1eMHc1RM+sTV7BFfUh6vcetjuFlUmaweb2oJG8510en7ajXBECp6t+lpWmXTSY8YsdEbmDeNaKzGdqEFW2iwlc17KSBs2XGkyoSRMBwu164JgI0Pw6qG68dhnmo6RRi7cuzUzsEAG2EF7kW8tS3rISigMbEcwEXyZ3s3fb26aD3YGhj9H/IkuW/X/0OCDIwAUePftzAxhNNW3R5RHZnKTz7I8tFgRp/C4dkeGOQVHoAfi+3v4TLk=

4. Defina a(s) branch(s) em que deseja realizar deploy, adicionando:

Para todas as branchs:

deploy:
  provider: heroku
  api_key: ...
  on:
    all_branches: true

Para uma branch específica (ex: branch chamada production):

deploy:
  provider: heroku
  api_key: ...
  on:
    branch: production

Heroku[editar | editar código-fonte]

Heroku é uma plataforma de nuvem com baseada em um sistema de contêiners, com serviços de dados integrados para implantação e execução de aplicativos.

O deploy automatizado está disponível no link: https://urutau-deploy.herokuapp.com/ Sempre que o desenvolvedor desejar realizar deploy deverá enviar suas modificações para a branch heroku-deploy.

Instalação[editar | editar código-fonte]

1. Instale o ruby (ou acesse: https://www.ruby-lang.org/pt/documentation/installation/#apt)

$ sudo apt-get install ruby-full

2. Instale o heroku:

$ wget -O- https://toolbelt.heroku.com/install-ubuntu.sh | sh

3. Agora o comando heroku está disponível pra ser utilizado mas é preciso se autenticar primeiro para usar o heroku:

$ heroku login
Enter your Heroku credentials.
Email: example@example.com
Password:

4. Crie um aplicativo no Heroku para que o Heroku se prepare para receber o código-fonte do seu projeto:

$ heroku create
Creating warm-eyrie-9006... done, stack is cedar-14
http://my-app-name.herokuapp.com/ | https://git.heroku.com/my-app-name.git
Git remote heroku added

5. Agora, deploy:

$ git push heroku master

Deploy: demais alternativas[editar | editar código-fonte]

Há várias possíveis alternativas para realizar o deploy com o Heroku, para o contexto deste trabalho foram estudas três delas:

  • Utlizando o Vagrant com Heroku;
  • Utilizando o Travis com Heroku;
  • Utilizando o Heroku sem integrar com outras ferramentas (somente o git).

Utlizando o Vagrant com Heroku[editar | editar código-fonte]

Documentação: https://www.vagrantup.com/docs/push/heroku.html

1.Defina a estratégia de deploy utilizando a estrutura abaixo no Vagrantfile:

config.push.define "heroku" do |push|
  push.app = "urutau_app"
end

2. Use o vagrant push para realizar o deploy

$ vagrant push

Utilizando o Travis com Heroku[editar | editar código-fonte]

Documentação: https://docs.travis-ci.com/user/deployment/heroku

O Travis CI pode distribuir automaticamente o app Heroku após uma build bem-sucedida. Para usar a configuração padrão, é preciso adicionar uma chave criptografada da API do Heroku no arquivo .travis.yml:

deploy:
  provider: heroku
  app: your-app-name # Opcional se o nome do app for o mesmo nome do repositório
  api_key: "INSERIR API TOKEN"

É possível gerar todo o trecho acima automaticamente através dos seguintes passos:

$ travis encrypt $(heroku auth:token) --add deploy.api_key
ou
$ travis setup heroku

Exemplo:

Passo de integração do Travis com o Heroku

Após o comando de encriptação, o .travis.yml foi alterado automaticamente com a adicição do seguinte trecho de código:

Trecho acrescentado após o comando "travis encrypt"

É possível definir a partir de qual branch será gerado o deploy; no exemplo abaixo, será a branch production.

deploy:
  provider: heroku
  api_key: ...
  on: production

Ao ser disparada a build automática, o deploy no app do Heroku é gerado automaticamente. Caso não haja sucesso na build, o deploy não é realizado.

Exemplo:

Trecho do Log do Travis CI
Status do deploy no Travis CI

Links Importantes[editar | editar código-fonte]

Referências[editar | editar código-fonte]

HASHIMOTO, M. Vagrant: Up and Running by Mitchell Hashimoto. United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

IEEE Computer Society. Pierre Bourque. Richard E. Fairly. SWEBOK v3.0. Guide to the Software Engineering Body of Knowledge. IEEE Computer Society Press. 2014.

GALE, Andy. Getting started with chef: First steps with chef. Disponível em: < http://gettingstartedwithchef.com/first-steps-with-chef.html >. Acesso em: 23 de maio de 2016.

TRAVIS CI. Docs. Disponível em: <https://docs.travis-ci.com/>. Acesso em: 28 de maio de 2016.

TYLLER GARRET. Exploring The Travis-CI Configuration File. Disponível em <http://blog.tgrrtt.com/exploring-the-travisci-configuration-file>. Acesso em: 28 de maio de 2016.

TARGETTRUST. Curso de Jenkins - Integração Contínua. Disponível em: <http://www.targettrust.com.br/curso/jenkins-integracao-continua>. Acesso em: 23 de abril de 2016.

WIKIPEDIA. Gerência de configuração de software. Disponível em: <https://pt.wikipedia.org/wiki/Gerência_de_configuração_de_software>. Acesso em: 23 de abril de 2016.

WIKIPEDIA. Software Configuration Management. Disponível em: <https://en.wikipedia.org/wiki/Software_configuration_management>. Acesso em: 23 de abril de 2016.

VAGRANT DOCS. Getting started. Disponível em: < https://docs.vagrantup.com/v2/getting-started/index.html >. Acesso em: 23 de maio de 2016..