Pesquini

Fonte: Wikiversidade

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

O presente documento visa descrever o Plano de Gerenciamento de Configuração de Software, a ser realizado no projeto Pesquini, sendo este desenvolvido por alguns integrantes da disciplina de Métodos de Desenvolvimento de Software da Universidade de Brasília. Este documento tem o intuito de descrever as atividades a serem executadas pelos integrantes Adailson Santos e Marcelo Martins de acordo com o cronograma proposto, além de informar as ferramentas utilizadas no decorrer do projeto.

Contexto[editar | editar código-fonte]

O projeto Pesquini visa construir um sistema que trata informações sobre empresas julgadas inidôneas, tornando-se não aptas a prestar serviços para o governo. O projeto visa disponibilizar as informações sobre empresas inidôneas de forma mais interativa e atrativa por meio de elementos visuais ,como gráficos, tabelas, rankings, mapas, entre outros, para a população em geral.

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

O documento será descrito a partir dos seguintes tópicos:

  • Introdução (contexto do projeto)
  • Repositório (link para o repositório do projeto)
  • Gerenciamento de Configuração (cronograma e ferramentas utilizadas)

Abreviações[editar | editar código-fonte]

  • UnB - Universidade de Brasília
  • GCS - Gerência de Configuração de Software
  • MDS - Métodos de Desenvolvimento de Software

Repositório[editar | editar código-fonte]

O repositório da aplicação Pesquini está disponível no seguinte link do Github: https://github.com/joaaogui/pesquini

O repositório da aplicação que está sendo utilizada para a disciplina está disponível no seguinte link do Github: https://github.com/adailson2/pesquini/tree/management

Relatório do Projeto[editar | editar código-fonte]

Cronograma[editar | editar código-fonte]

O cronograma foi elabora conforme as demandas de projetos e atividades das outras disciplinas, buscou-se então, atividades mais trabalhosas em épocas que a dupla estiveram mais tranquilos com relação as outras atividades da universidade.

Utilizamos Sprints para facilitar a localização no desenvolvimento do projeto.

Milestone Sprint Período Atividade Status
Planejamento 1 20/09 ~ 26/09 Fazer Plano de GCS Feito
2 27/09 ~ 03/10 Definir ferramentas de configuração Feito
3 04/10 ~ 10/10 Desenvolver Política de Branch Feito
Máquina Virtual 4 11/10 ~ 17/10 Criar e configurar máquina virtual (Vagrant) Feito
Integração Contínua 5 17/10 ~ 25/10 Estudar ferramenta de integração contínua (Travis) Feito
6 26/10 ~ 01/11 Implementar ferramenta de integração contínua Feito
7 07/11 Ponto de Controle Feito
Deploy automatizado 6 08/11 ~ 14/11 Estudar ferramenta de deploy (Heroku) Feito
7 15/11 ~ 21/11 Implantação e teste do deploy Feito
21/11 Entrega Projeto Final
28/11 Entrega Projeto Final
05/12 Entrega Projeto Final

Ferramentas[editar | editar código-fonte]

As ferramentas que a equipe planeja desenvolver no projeto são as seguintes:

Ferramenta Descrição
Git
GitHub Sistema de hospedagem de repositório
Vagrant Virtualização de ambiente
Travis Ferramenta de Configuração Contínua
Heroku Ferramenta de Deploy Automatizado
PostGre SQL

Execução do Projeto[editar | editar código-fonte]

Planejamento[editar | editar código-fonte]

Executou-se o planejamento no tempo previsto no cronograma. A dupla desenvolveu um Plano de Gerenciamento de Configuração contendo as ferramentas que serão trabalhadas no projeto Pesquini. O projeto Pesquini foi desenvolvido pela disciplina Métodos e Desenvolvimento de Software da turma de 2014 e o mesmo não possuiu um gerenciamento de configuração de software bem definido e esse foi o principal motivo da escolha desse projeto para ser trabalhado na disciplina de Gerência e Configuração de Software.

Máquina virtual[editar | editar código-fonte]

Uma ambientação virtual se torna necessária em um projeto que necessita de praticidade quando a equipe de desenvolvimento deseja trabalhar em uma máquina com as mesmas configurações e ferramentas. Dentre as ferramentas para essa ambientação utilizou-se o Vagrant, pois possui uma ótima documentação e possui fácil instalação.

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

Primeiramente, foi necessário a instalação do Vagrant e do Virtualbox:

Acessou-se a página de download do Vagrant e instalou o mesmo de acordo com as configurações de sistema da máquina. Além disso, foi necessário a instalação da ferramenta VirtualBox para emular o ambiente juntamente com o Vagrant.

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

Seguindo a documentação do Vagrant, foi realizado os seguintes comandos dentro da pasta GCS:

$ vagrant init ubuntu/trusty64

Utilizou-se a box "ubuntu/trusty64" pois foi a mais adequada ao projeto. Desse modo, o vagrant criou um arquivo chamado Vagrantfile. Custamizamos o VagrantFile da seguinte forma:

Vagrant.configure(2) do |config|

   config.vm.provision :shell, path: "install-rvm.sh", args: "stable", privileged: false
   config.vm.provision :shell, path: "install-ruby.sh", args: "2.3.1", privileged: false
   config.vm.provision :shell, path: "install-ruby.sh", args: "2.3.1 rails haml", privileged: false
   config.vm.provision :shell, path: "install-postgresql.sh", args: "9.5.4", privileged: false

   config.vm.provision "shell", inline: <<-SHELL
     sudo apt-get update
     sudo apt-get install -y nodejs nodejs-legacy postgresql-common postgresql-9.5
     sudo apt-get install -y git curl automake build-essential bison
     sudo apt-get install -y libpq-dev libssl-dev libtool libcurl4-openssl-dev
     sudo apt-get install -y libyaml-dev libreadline-dev libxml2-dev libxslt1-dev
     sudo apt-get install -y libffi-dev libffi-dev libgdbm-dev libncurses5-dev
     sudo apt-get install -y libsqlite3-dev sqlite3 zlib1g-dev
     sudo apt-get install -y python-software-properties
     rvm default ruby-2.3.1
     gem install bundler
     gem install nokogiri -v '1.6.8'
     gem install rails  
     sudo apt-get autoremove
     sudo apt-get autoclean
     sudo apt-get update
     cd /vagrant/
     bundle install
    SHELL
end

Observa-se a instalação dos seguintes paths: "install-rvm.sh", "install-ruby.sh", "install-postgresql.sh".

Para que sejam instaladas com sucesso, fori necessário a criação desses 3 arquivos:

install-rvm.sh

#!/usr/bin/env bash
gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
curl -sSL https://get.rvm.io | bash -s $1

install-ruby.sh

#!/usr/bin/env bash

source $HOME/.rvm/scripts/rvm

rvm use --default --install $1

shift

if (( $# ))
then gem install $@
fi

rvm cleanup all

install-postgresql.sh

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" >> /etc/apt/sources.list.d/pgdg.list'

wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O - | sudo apt-key add -

Portanto, na pasta criada, ficou o seguinte:

$ ls -a
.   install-postgresql.sh  install-rvm.sh  install-ruby.sh
..  Vagrantfile

Agora é só executar o comando abaixo para que seja criado a máquina virtual e instalado as dependências necessárias para a execução e desenvolvimento do projeto Pesquini:

$ vagrant up --provider virtualbox

Após a instalação completa da ambientação, é necessário executar o seguinte comando para entrar na máquina:

$ vagrant ssh

É possível observar que se está dentro da máquina quando o comando de acesso do terminal esteja no seguinte formato:

vagrant@vagrant-ubuntu-trusty-64:~$

Para criar uma pasta compartilhada com a pasta local do projeto é necessário entrar na pasta oculta do vagrant:

vagrant@vagrant-ubuntu-trusty-64:~$ cd /vagrant
vagrant@vagrant-ubuntu-trusty-64:/vagrant$

Agora é só fazer o clone do repositório disponível no github e trabalhar normalmente:

vagrant@vagrant-ubuntu-trusty-64:/vagrant$ git clone https://github.com/adailson2/pesquini/

Integração Contínua[editar | editar código-fonte]

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

Para a implementação de um projeto com a geração de testes funcionais, unitários e de sistema a cada contribuição de projeto, configurou-se o Travis CI.

Primeiramente, foi necessário entrar no repositório no GitHub do projeto e adicionar o serviço Travis CI na área de "Settings".

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

Após isso, ao entrar no site do Travis CI e vinculá-lo a conta do GitHub, foi possível ativar o repositório para a execução do Travis.

O mesmo orientou de criar uma aplicação chamada .travis.yml e inserir na raiz do projeto.

.travis.yml

language: ruby
rvm:
  - "2.3.1"

addons:
  postgresql: "9.5.4"

before_script:
  - sudo service postgresql start
  - cd pesquini/
  - gem install rspec rspec-rails simplecov
  - bundle install
  - psql -c 'create database pesquini_test;' -U postgres;
  - psql -c 'create user pesquini;' -U postgres;
  - rake db:migrate
  - rake db:setup

script:
  - bundle exec rspec spec
  - bundle exec cucumber

bundler_args: --binstubs=./bundler_stubs

sudo: required

notifications:
  email:
    recipients:
      - adailson2@gmail.com

Foi desenvolvido, então, esse script contendo a versão da linguagem da aplicação, a criação de database e user no banco e o comando execução dos testes.

Ao realizar o push na aplicação, foi observado no GitHub que ao lado do commit, apareceu um ícone verde positivo, sinal de que a build foi executada e testada naquele commit.

Deploy[editar | editar código-fonte]

O deploy da aplicação foi realizado utilizando o Heroku. Para que o deploy fosse realizado, foi necessário pré-compilar todos os assets e a realização do teste local para a verificação de algum possível bug na hora de dar o deploy. Após essa verificação foi utilizados os seguintes comandos:

É necessário logar com a senha e usuário do heroku através desse comando:

heroku login

Após estar logado, foi utilizado este comando, que serve para transformar o código implantado em slug , que poderão ser então executado em uma dyno. Esse comando irá recuperar todas as dependências, gerar ativos gerados ou código compilado.

heroku create --buildpack https://github.com/heroku/heroku-buildpack-ruby.git

Logo em seguida demos o seguinte comando para a verificação da aplicação:

git config --list | grep heroku

Após isso inicializamos o banco, porém não o populamos:

heroku run rake db:migrate

Com o seguinte comando, subimos a aplicação para o servidor do heroku:

git push heroku master

Após isso, abrimos a aplicação:

heroku open