FromThePage
Alunos: Júlio Xavier e Lucas Andrade
Introdução
editarNessa 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
editarFinalidade - 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
editarEste 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
editarAbaixo 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
editarFerramentas
editarHoje 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. |
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
editarPapel | 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
editarTodo 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
editarPara 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
editarPara 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
editarFoi 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
editarSerã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
editarPara 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
editarConsiderando 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".
Resolução de Issues
editarO nome da branch deverá conter a identificação da Issue.
editarExemplo:
Caso haja uma issue como "Issue 01 - Error retrieving nickname" a branch a ser criada deverá ser nomeada como "Issue01", ou ainda, "IssueRetNickname".
Merge
editarO 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
editarPara 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
editarPara 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
editarhttps://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://gorails.com/guides/using-vagrant-for-rails-development