FromThePage

Alunos: Júlio Xavier e Lucas Andrade

Introdução

Nessa página estão descritos as etapas de planejamento e aplicação das atividades executadas durante a disciplina de Gerência de Configuração de Software (GCS).

O projeto escolhido para a execução das atividades foi o FromThePage, um site para tradução e digitalização de manuscritos. É uma rede social livre no qual pessoas podem publicar fotos de manuscritos para que alguém faça a digitalização do mesmo, ao final do processo é possível gerar uma versão digital do documento.

O fork do projeto para disciplina se encontra no link https://github.com/LucasAndrad/fromthepage

Visão geral

Finalidade - Elucida os objetivos do plano.

Escopo - Aprofunda os pontos que serão abordados na execução do projeto.

Cronograma - Definição de datas para a execução do plano de Gerência de Configuração de Software.

Pessoas - Principais papéis e breve descrição.

Finalidade

Este plano possui a finalidade de guiar e especificar ações, objetivos e papéis que auxiliem na melhoria da Gerência de Configuração do software From The Page. Serão contempladas as ferramentas utilizadas, papéis no projeto, cronograma e também relatório de projeto.

Escopo

Abaixo estão listados os itens que o grupo pretende acrescentar ao projeto FromThePage:

• Configuração de ambiente automatizada.
• Integração contínua utilizando Travis CI.
• Desenvolver uma política de branch e commit: criação, exclusão, merge de branch e versionamento.
• Deploy automatizado.

Plano de Gerência e configuração do projeto

Ferramentas

Hoje em dia para o desenvolvimento ou evolução de uma aplicação web, os responsáveis podem contar com diversas ferramentas que auxiliam durante o processo de desenvolvimento e manutenção. Abaixo estão listadas algumas ferramentas que a equipe pretende utilizar ao longo do projeto.

Ferramenta	Sinopse
Travis CI	Ferramenta que permite integração contínua com diversas linguagens, entre elas Ruby on Rails, linguagem utilizada no projeto.
Vagrant	Ferramenta que permite a configuração do ambiente para que os desenvolvedores tenham um projeto funcional em suas máquinas.
Ruby Gems	Pacotes que ajudam na implementação de novas funcionalidades.
Git	Gerenciador de versões utilizado no projeto
GitHub	Plataforma (Source forge) responsável por guardar e gerenciar as versões e mudanças do projeto na nuvem.
WhatsApp	Utilizada para comunicação entre a equipe de projeto.
Google Drive	Utilizada para o compartilhamento de fontes/arquivos pertinentes para a execução do projeto.
Gmail	Utilizada para notificações do Travis CI e comunicação com monitores da disciplina.

Pessoas

Papel	Descrição e responsabilidades	Responsáveis
Desenvolvedor	Responsável pela implementação do código, deve seguir as políticas de branch definidas. O mesmo será afetado diretamente pela configuração de ambiente e integração contínua.
Gestor de configuração	Responsável por definir quais mudanças de configuração serão feitas no projeto e quais ferramentas serão utilizadas, baseado em suas necessidades e contexto.	Júlio Xavier e Lucas Andrade
Auditor de configuração de software	Responsável por fazer verificação e validação do plano de Gerência de Configuração de Software.	Renato Sampaio

Cronograma

Todo projeto, seja na criação ou em evoluções do produto, deve seguir um roteiro com datas e atividades (cronograma) definidas pela equipe responsável pelo projeto. Isso ajuda na organização da equipe e permite que todos vejam a qualquer momento o que deve ser feito e quando deve ser feito. Abaixo está definido o cronograma da equipe.

Sprint	Atividade	Data	Status
1	Definir plano de GCS	20/09 - 03/10	Concluído
2	Configuração de ambiente (equipe)	04/10 - 10/10	Concluído
3	Configuração de ambiente automatizada	11/10 - 17/10	Concluído
4		18/10 - 24/10	Concluído
5	Integração contínua	25/10 - 31/10	Parcial
6		01/11 - 07/11	Parcial
7	Política de Branch e política de commits	08/11 - 14/11
8	Deploy automatizado	15/11 - 21/11
9		22/11 - 26/11
10	Apresentação dos grupos	28/11 e 05/12

Ambiente automatizado

Para contribuir com qualquer projeto aberto no GitHub, GitLab, etc., é necessário configurar o ambiente de desenvolvimento antes de começar a trabalhar no projeto, essa é uma atividade que muitas vezes se torna cansativa, devido a divergências relacionadas aos sistemas operacionais utilizados pelos desenvolvedores, por exemplo. Com o Vagrant é possível criar uma máquina virtual que emula um sistema operacional independente do que o usuário usa atualmente.

Além disso é possível ainda utilizar um arquivo shell script que configura todo o ambiente de desenvolvimento, instalando as versões e dependências necessárias para trabalhar no projeto que se deseja.

A equipe de projeto utilizou o Vagrant e o Virtual Box para criar a máquina virtual, e também foi um arquivo Shell Script (.sh) para instalar as dependências do projeto.

A baixo temos o arquivo Vagrantfile, que configura qual máquina virtual será criada, a memória que essa máquina vai utilizar, define qual porta localhost a virtual machine irá sincronizar, e também é definido qual arquivo Shell Script o Vagrant irá executar.

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  # Use Ubuntu 16.04 Xenial Xerus 64-bit as our operating system
  config.vm.box = "ubuntu/xenial64"
  
  # Config port for vagrant rails project
  config.vm.network "forwarded_port", guest: 3000, host: 3000

  # Configurate the virtual machine to use 2GB of RAM
  config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--memory", "2048"]
  end

  config.vm.provision "shell", privileged: false, path: "script_vm.sh"
  # privileged: false, inline: $script
end

Com o arquivo Vagrantfile pronto, para criar a máquina virtual basta rodar o comando:

$ vagrant up

E para entrar na VM deve usar o comando:

$ vagrant ssh

Abaixo temos o arquivo Shell Script que instala todas as dependências do projeto, começando pelas instalações básicas como MySQL e Git, passando pela instalação da versão correta do Ruby, do Ruby On Rails e das demais dependências do projeto. Por último, instala as gems necessárias do projeto com o comando bundle install.

#!/bin/sh

# - rbenv and ruby-build
# - ruby 2.3.1 with bundler
# - Git 1.9.1
# - SQLite
# - Node.js
# - ImageMagick

# enable console colors
sed -i '1iforce_color_prompt=yes' ~/.bashrc

# disable docs during gem install
echo 'gem: --no-rdoc --no-ri' >> ~/.gemrc

# essentials
sudo apt-get update
sudo apt-get install -y git-core curl zlib1g-dev build-essential libssl-dev libreadline-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt1-dev libcurl4-openssl-dev python-software-properties libffi-dev

# SQLite, Git and Node.js
sudo apt-get install -y git
sudo apt-get install -y mysql-server
sudo apt-get install -y mysql-client libmysqlclient-dev
curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y nodejs

# ImageMagick
sudo apt-get install -y imagemagick
sudo apt-get install -y libmagick++-dev

# setup rbenv and ruby-build
git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build

# Install ruby 2.3.1 and bundler
export RBENV_ROOT="${HOME}/.rbenv"
export PATH="${RBENV_ROOT}/bin:${PATH}"
export PATH="${RBENV_ROOT}/shims:${PATH}"
rbenv install 2.3.1
rbenv global 2.3.1
gem install bundler
rbenv rehash

gem install --no-rdoc --no-ri rails 4.1.2
rbenv rehash

# app specifics
cd ../../
cd vagrant
bundle install
rbenv rehash

# cleanup
sudo apt-get clean

Para que o Vagrant execute o script é necessário sair da máquina virtual e executar o comando:

$ vagrant provision

Integração Contínua

Para utilizar a integração contínua com o Travis CI é necessário criar uma conta e sincronizar sua conta do GitHub com o Travis. Feito isso basta escolher o projeto e sincronizá-lo com o Travis, isso é feito no menu de projetos no site da ferramenta.

A equipe optou por sincronizar a conta do GitHub com o Travis.

Com a conta sincronizada o próximo passo é criar um arquivo .travis.yml, nesse arquivo estão definidos os passos que o Travis irá executar para rodar os testes do projeto.

A seguir, pode-se observar a configuração do arquivo .travis.yml para o projeto FromThePage:

language: 
  - ruby

rvm:
  - 2.3.1

script:
    - gem install rspec-rails
    - gem install rspec
    - gem install factory_girl
    - gem install rake
    - gem install mysql
    - bundle exec rake db:create RAILS_ENV=test
    - bundle exec rake db:migrate RAILS_ENV=test
    - bundle exec rake db:migrate:status
    - bundle exec rspec spec

services:
  - mysql

notifications:
  email:
    recipients:
      - lucasandradeunb@gmail.com
      - julioxavierr@gmail.com

branches:
  only:
    - gcs

No arquivo temos a linguagem do projeto, o banco de dados que ele vai utilizar, a(s) branch(s) monitorada, os destinatários para as notificações via e-mail e o script a ser executado pelo Travis.

Política de branch e commit

Foi utilizado como ferramenta de versionamento o Git e como forge o GitHub, no qual há um fork do projeto disponível publicamente contendo as mudanças realizadas.

Branchs principais

Serão definidas duas branchs principais com versões mais estáveis do projeto.

Branch master: Versões do projeto estáveis que serão enviados para produção, ou seja, que estarão disponíveis para os usuários. Esta branch é atualizada pelas versões mais estáveis da branch development periodicamente.

Branch development: Utilizada para a integração de diferentes funcionalidades do projeto, objetivando a estabilidade do código para que a versão possa ser integrada à branch master. Esta branch é atualizada por outras branchs utilizadas para o desenvolvimento de novas funcionalidades.

Integrações nas branchs acima descritas que não sigam essas regras serão desconsideradas.

Criação de branch

Para criação de branch será necessário nomeá-las segundo seu objetivo, seja criação de uma nova funcionalidade ou resolução de issues.

Nova funcionalidade

Considerando que o projeto é guiado por estórias de usuário, a criação de uma nova funcionalidade deve possuir a identificação da estória que será implementada. Caso seja necessário mais de uma branch para uma mesma estória, poderá ser adicionada alguma informação adicional para identificação.

A branch de nova funcionalidade deverá ser criada sempre a partir da branch development.

Exemplo:

Caso haja uma estória como "US 01 - Eu, como cliente, desejo poder criar uma conta para ter acesso ao sistema." a branch a ser criada deverá ser nomeada como "us01", e ainda, caso seja necessária criar uma branch para autenticação com Facebook, por exemplo, o nome poderia ser "us01-facebook".

O nome da branch deverá conter a identificação da Issue.

Exemplo:

Caso haja uma issue como "Issue 01 - Error retrieving nickname" a branch a ser criada deverá ser nomeada como "Issue01", ou ainda, "IssueRetNickname".

Merge

O merge ou pull-request sempre deverá ser realizado na branch a partir da qual a nova branch para resolução da issue foi criada. Por exemplo, se foi criada uma branch para resolução de issue a partir da branch "us01-facebook", a mesma deverá ser integrada à branch "us01-facebook" após sua conclusão.

Commits

Para a realização de commits, deverá ser seguido o padrão a seguir:

• O commit deve ser realizado em inglês.
• O commit deve descrever brevemente quais mudanças foram realizadas.
• Primeira letra do título e corpo (caso exista) maiúscula.
• Commits de merge devem indicar os conflitos ocorridos.
• Sempre deve ser indicado no commit o autor.
• Caso exista co-autor, deve ser indicado utilizando signed-off-by.

Deploy Automatizado - Heroku

Para automatizar o deploy da aplicação, ou seja, aplicar as mudanças do commit diretamente na aplicação. Para vamos utilizar o Heroku

Primeiramente é necessário criar uma conta no Heroku, e instalar o Heroku CLI.

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

Em seguida basta fazer o login com sua conta do Heroku

heroku login
Enter your Heroku credentials.
Email: example@email.com
Password: 
Could not find an existing public key.
Would you like to generate one? [Yn]
Generating new SSH public key.
Uploading ssh public key /Users/adam/.ssh/id_rsa.pub

Caso a aplicação utilize um banco de dados deve-se utilizar o Postgre

Para fazer a mudança basta substituit sua gem referente ao banco atual pela gem:

gem 'pg'

Em seu database.yml troque o adapter atual pelo:

adapter: postgresql

E necessário criar um aplicativo Heroku, dentro da pasta do projeto digite:

heroku create

Agora vamos realizar o deploy pela linha de comando:

git push heroku master

Para migrar sua base de dados digite:

heroku run rake db:migrate

Em seguida basta visualizar a aplicação no Browser com comando:

heroku open

Também é possível integrar o Heroku com o Travis CI, assim antes da mudança ser integrada na aplicação, a integração contínua atua testando o código e evitando que erros não sejam aplicados no projeto. Primeiro é necessário baixar a gem travis:

gem install travis

Gerar uma chave de segurança criptografada:

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

Copie a chave gerada (é um string)

Com isso são geradas algumas linha no arquivo .travis.yml

deploy:
  api_key:
    secure: CHAVE CRIPTOGRAFADA
  on: master

Referêcias

https://devcenter.heroku.com/articles/getting-started-with-rails4

https://devcenter.heroku.com/articles/heroku-postgresql#local-setup

https://devcenter.heroku.com/articles/heroku-command-line

https://www.mrprompt.com.br/2016/03/25/integracao-continua-travis-ci/

https://tasafo.org/2014/10/06/entrega-continua-com-ruby-on-rails-github-code-climate-travis-ci-e-heroku/

https://gorails.com/guides/using-vagrant-for-rails-development

http://martinfowler.com/articles/vagrant-chef-rbenv.html

https://www.vagrantup.com/docs/provisioning/shell.html