Proconsulta

Introdução

Propósito

O seguinte plano de gerência de mudança visa automatizar o deploy da aplicação, a criação do ambiente de desenvolvimento, bem como do ambiente de produção, melhorando assim todo o processo de gerência de mudança e configuração do Proconsulta.

Escopo

O seguinte plano de gerência de mudança será aplicado ao Proconsulta, sistema web para qualificação do atendimento realizado nos postos de atendimento do Procon.

O Proconsulta utiliza o Git como sistema de controle de versão, bem como o GitHub.com como forge, porém não realiza integração contínua. Há também carência de documentação de configuração de ambiente além de inexistência de ambiente de produção.

Todos esses fatores tornam o projeto difícil de ser configurado e mantido, desacreditando possíveis colaboradores e dificultando qualquer processo de gerência de mudanças.

Gerência de Configuração de Software

Organização, Responsabilidades e Interfaces

O plano de gerência de configuração de software bem como a implementação do mesmo no projeto Proconsulta tem como responsáveis os futuros engenheiros de software:

• Dylan Guedes
• Eduardo Vital

A equipe se organizará de forma a sempre trabalhar em conjunto para a aplicação do plano de configuração e mudança no projeto Proconsulta.

Ferramentas, Ambiente e Infraestrutura

Capistrano

O Capistrano será a ferramenta que cuidará do deploy automatizado do sistema no ambiente de produção.

Chef

Para automatização da infraestrutura do projeto (como o software é entregue e mantido em um servidor) será utilizado o Chef. Assim todo o processo de configuração dos ambientes será automatizado, melhorando e facilitando a manutenção e configuração dos ambientes.

Vagrant

O Vagrant será utilizado para a criação dos ambientes de desenvolvimento e produção, facilitando a implantação e migração, e reduzindo drasticamente o tempo que se levaria, por exemplo,  para o levantamento de um ambiente de desenvolvimento de um novo colaborador do projeto.

Git

O projeto continuará  utilizando o sistema de controle de versão Git a fim de controlar e gerenciar as mudanças ocorridas no projeto.

Gitlab CE

O projeto passará a utilizar a forge GitLab CE em detrimento do GitHub.com. Essa mudança ocorrerá  para que se possa ter controle total sobre a forge, mantendo-a em um servidor próprio.

Gitlab CI

O projeto passará a utilizar o GitLab CI como ferramenta de integração contínua. Com isso espera-se reduzir os problemas enfrentados no processo de integrar o trabalho desenvolvido por diferentes integrantes da equipe. A integração contínua ocorrerá de forma automatizada, o que conferirá maior agilidade e comodidade no processo de integração.

DigitalOcean

Será utilizado o serviço de hospedagem em nuvem DigitalOcean a fim de manter o ambiente de produção no ar sem precisar alocar uma estrutura própria de servidores, o que confere uma maior facilidade e confiabilidade ao ambiente de produção.

Bash Script

Processador de comandos que interage com os comandos do script do Unix. Será utilizado na automatização de determinadas partes do projeto. Apresenta a vantagem de não ser necessária qualquer configuração (desde que o ambiente seja Unix), diferente do Chef.

Gerência de Configuração de Programa

Identificação da Configuração

A baseline para implementação do plano será a versão com label Release 2 no repositório do projeto (se trata da versão final estável).

Configuração e Controle de Mudança

As mudanças serão implementadas num fork do projeto de forma isolada. Quando estiverem concluídas, será feito um merge request para o repositório oficial do projeto. O merge será analisado e revisado, e, caso atenda aos critérios, será aceito.

Relato do Status de Configuração

Será utilizado uma ferramenta de controle de versão para armazenamento das diferentes mudanças ocorridas, garantindo a segurança do processo.

Caso algo desastroso ocorra, existem algumas opções:

Comando	Objetivo
git reset --hard CodigoDoCommit	Será utilizado quando se deseja discartar várias mudanças e se voltar a um commit estável.
git checkout Arquivos	Será utilizado quando se deseja discartar mudanças que não foram salvas.
git rebase -i HEAD~indice	Será utilizado quando se deseja refazer a base de commits já feitos. Será particularmente util para tratar conflitos e ordem de diferentes commits.
rake db:migrate:rollback	Será utilizado para voltar o banco de dados à ultima migração estável.
vm gemset empty	Será utilizado para limpar a gemset do rvm.

Ainda existem outras maneiras (como reclonar o repositório), mas as medidas acima provavelmente serão suficientes.

Release

A release será baseada na automatização de processos necessários em um software livre já concluido. Essa automatização encorajará possíveis novos contribuidores, melhorará a qualidade do processo, e servirá de suporte aos desenvolvedores.

Mudanças com Relação ao Plano

Troca do Gitlab CI pelo Jenkins

O Proconsulta, desde sua origem, sempre foi hospedado na forge Github. O grupo levou o Proconsulta também para o Gitlab, mas o projeto em si tinha acompanhamento somente no Github. Daí surge a primeira questão: O Gitlab CI limita o sistema a utilizar o Gitlab. Outra questão que influenciou na decisão foi o fato do Jenkins ser muito flexível e consolidado (o Gitlab CI mudou recentemente o sistema de jobs, e também recentemente começou a utilizar o sistema de yml, já o Jenkins ocorre da mesma maneira já há algum tempo). E, por ultimo, o sistema com que o Jenkins trabalha (de service) ao invés do sistema de runners, instancias e jobs (do Gitlab) se adequa melhor à proposta do grupo, que já tinha em mãos uma vm no Digital Ocean livre para ser utilizada.

Migração do Rails3.2.15 e Ruby1.9.3 para o Rails4.2.0 e Ruby2.2.0

Com a mudança de ultima hora do serviço de integração contínua sem um aviso prévio ao professor da disciplina, e a não utilização do Chef (que embora não tinha sido explicito que seria utilizado, tinha-se em mente), a dupla sentiu a necessidade de fazer algo a mais, "pagando" uma possível "dívida técnica". A mudança para o rails4 e ruby2 se faz necessária pois o ruby1 e o rails3 já são relativamente antigos (coisa de 3 anos), e em pouco tempo sairá o ruby3 e o rails5, e a migração do rails3/ruby1 para o rails5/ruby3 seria quase impossível de se fazer "diretamente", sendo necessária a ponte com o rails4 de um jeito ou de outro.

Não utilização do Chef

Durante a criação do plano, a dupla tinha em mente a utilização do Chef para automatização do processo de configuração. Contudo, foi uma escolha não tão bem pensada, e desnecessária (em nenhum momento sentiu-se necessidade de uma automatização com o Chef - A automatização com o bashscript no PC1 já foi mais que suficiente).

Relatório de Acompanhamento/Tutorial

Nesse capítulo será dado um overview a respeito da abordagem da dupla quanto as técnicas de gerência de configuração utilizadas, e ideias de como reproduzir resultado semelhante.

Obs: todo o progresso feito durante a disciplina pode ser visualizado no GitLab do Proconsulta na branch rails4

Hospedagem - DigitalOcean

Utilizamos um droplet do Ubuntu 14.04 com 2GB de memória, SSD de 40GB,Dual core, o servidor localizado em Nova Iorque, Estados Unidos.

Foi escolhido o Ubuntu devido à sua ampla utilização e sua facilidade na disponibilização de pacotes necessários para o projeto. Para garantir a segurança e estabilidade necessárias, foi utilizado a versão 14.04 LTS que tem suporte garantido até o fim do primeiro semestre de 2019.

Alocamos 2GB de memórias, devido à preocupação em garantir a estabilidade do sistema, garantindo uma folga para futuros aprimoramentos e a possibilidade de utilizar Vagrant e/ou Docker dentro do servidor.

O espaço de armazenamento não era uma preocupação, não sendo necessário alocar 40GB para a aplicação, porém não havia opção para reduzir o espaço de armazenamento. Caso fossemos utilizar um servidor próprio, teríamos alocado apenas 20GB. Mas é importante ressaltar que o DigitalOcean disponibiliza o espaço de armazenamento em SSDs(Solid State Disks), o que garante um importante ganho de desempenho no acesso aos arquivos e à aplicação em si, o que impacta diretamente na experiência do usuário.

O processador dual core garante um maior desempenho ao servidor por permitir um paralelismo de processamento.

Segundo informações da Documentação do GitLab CE essa configuração permite o acesso de 500 usuários. Como nosso servidor contará com outros serviços além do GitLab CE, esperamos suportar a demanda de 100 usuários simultâneos, o que consideramos um bom número para uma aplicação nova e sem pouca repercussão.

Instalação do GitLab CE

O script abaixo foi criado por nós para a instalação do GitLab CE em uma droplet virgem do DigitalOcean - Ubuntu 14.04 com 2GB de memória.

#!/bin/bash
clear

echo "Verificando Swap..."
echo
if [ $(grep -c "/swapfile none swap defaults 0 0" /etc/fstab) -ne 0 ]
then
  echo "Swap já foi ativada"
else
  echo "Swap não encontrada"
  echo "Configurando Swap de 2GB..."
  echo
  fallocate -l 2G /swapfile
  chmod 600 /swapfile
  mkswap /swapfile
  swapon /swapfile
  echo "/swapfile none swap defaults 0 0" >> /etc/fstab
fi

echo
echo "Atualizando sistema"
echo
apt-get update -y
apt-get upgrade -y

echo
echo "Instalando dependências do Gitlab CE"
echo
debconf-set-selections <<< "postfix postfix/main_mailer_type string 'Internet Site'"
debconf-set-selections <<< "postfix postfix/mailname string proconsulta.org"
apt-get install -y curl openssh-server ca-certificates postfix

echo
echo "Adicionando o pacote do GitLab CE e instalando-o"
echo
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
apt-get install -y gitlab-ce

echo
echo "Configurando e inicializando o GitLab CE"
echo
gitlab-ctl reconfigure

Após o script ser executado, basta acessar o endereço do servidor e entrar com as seguintes credenciais:

Username: root  Password: 5iveL!fe

Para configurações avançadas, utilizar como referência o Guia de Pós Instalação do GitLab CE.

Automatização - Bashscript

O processo de rodar as migrações, dar bundle install, rodar o rspec, etc, é repetido diversas vezes durante a produção do Proconsulta (e dos softwares em Ruby on Rails, no geral). Por tal motivo, sentiu-se a necessidade de automatização desse fluxo de comandos, utilizando-se bashscript. Para rodar o script, primeiro roda-se o arquivo configure-proconsulta, através do comando (na pasta do projeto):

$ ./configure-proconsulta

Esse comando basicamente copia o arquivo proconsulta para uma pasta bin e da export no PATH, fazendo com que o comando proconsulta passe a funcionar em qualquer diretório. O conteúdo do comando proconsulta é:

#!/bin/bash

source /usr/local/rvm/scripts/rvm
bundle install
rake db:migrate
rspec
rails s

Com pequenas adaptações, é possível utilizar esse script para que ele seja utilizado pelo jenkins, ao invés de colocar o processo manualmente. Contudo, dessa maneira está suficiente para a automatização dos comandos.

Capistrano - Deploy automatizado

Para instalar o capistrano, foi adicionado as seguintes gems no Gemfile:

# Deploy with Capistrano
gem 'capistrano'
gem 'capistrano-rvm'

Após executar o comando bundle install, o comando cap install para gerar os arquivos de configuração do capistrano:

• Capfile
• config/deploy.rb
• config/deploy/staging.rb
• config/deploy/production.rb

O arquivo staging.rb não foi utilizado.

Os arquivos foram configurados da seguinte forma:

Capfile

# Load DSL and set up stages
require 'capistrano/setup'

# Include default deployment tasks
require 'capistrano/deploy'

# Include tasks from other gems included in your Gemfile

require 'capistrano/rvm'

# Load custom tasks from `lib/capistrano/tasks` if you have any defined
Dir.glob('lib/capistrano/tasks/*.rake').each { |r| import r }

config/deploy.rb

# config valid only for current version of Capistrano
lock '3.4.0'

# Application name 
set :application, 'proconsulta'

# Repository URL
set :repo_url, 'git@gitlab.com:UNB-GPPMDS-2014/Proconsulta.git'

# Default value for :scm is :git
set :scm, :git

# User
set :user, "root"

namespace :deploy do
  after :deploy, 'deploy:database'

  # Configure server database
  task :database, :roles => :app do
      run "cp #{deploy_to}/shared/database.yml #{current_path}/config/"
  end
end

config/deploy/production.rb

# server-based syntax
# ======================
# Defines a single server with a list of roles and multiple properties.
# You can define all roles on a single server, or split them:

server '104.131.82.30', user: 'root', roles: %w{app db web}

Repare que '104.131.82.39' deve ser substituído pelo endereço do servidor desejado, e 'root' pelo usuário com acesso ao servidor.

Execução

• Para checar se está tudo okay, execute o comando: cap deploy:check
• Para configurar pela primeira vez o diretório de deploy do servidor, execute o comando: cap deploy:setup
• Para fazer o deploy, execute o comando: cap deploy

Note que não é necessário estar no servidor para executar os comandos acima (pelo contrário).

Jenkins

Antes de qualquer coisa, deve ser esclarecido que a principal fonte de aprendizado para o Jenkins foi esse post, por Andy Wong, em 2013: http://www.intridea.com/blog/2013/5/21/howto-install-setup-jenkins-ci-for-rails-projects

O ambiente em que foi implantado o Jenkins foi uma vm com ubuntu 14.04.

Passos seguidos: 1. Foi instalado inicialmente as dependências necessárias para a instalação do RVM, já que o projeto é em Ruby on Rails. Instalar Ruby sem RVM é muito arriscado, pois cedo ou tarde será necessária outra versão, e essa troca pode trazer muita dor de cabeça. Para instalar o rvm é necessário o curl, o git-core e o build-essential instalam possíveis dependências:

$ sudo apt-get install curl
$ sudo apt-get install build-essential git-core

2. É altamente sugerido a utilização de um user separado no seu ambiente Unix, ao invés de instalar no seu próprio usuário. Nessa parte o tutorial seguido (e referenciado) não explica como adicionar um novo usuário no sistema. Os passos são os seguintes:

$ sudo adduser jenkins

3. O usuário jenkins ainda está sem privilégios de sudo. Adicione-os, com: 3.1. Entre no visudo (o sudoers é lockado):

$ sudo visudo

3.2. Procure a lingua que contém a expressão:

root ALL=(ALL:ALL) ALL

3.3. Abaixo da linha mencionada, copie e cole a linha, trocando a palavra root por jenkins:

jenkins ALL=(ALL:ALL) ALL

4. Entre no usuário jenkins:

$ sudo su jenkins

5. Agora sim, instale o rvm, SEM SUDO. Dessa forma, somente o usuário jenkins tem essa versão X da instalação do rvm (aí o usuário jenkins fica isolado dos outros):

$ curl -L https://get.rvm.io | bash

6. Se necessário, adicione a key gpg informada pelo comando anterior, e rode o comando novamente. Aceite a key. 7. Agora com o rvm configurado, dê source na pasta do rvm. No caso do grupo, a pasta ficou: <syntaxhightlight lang="bash"> $ source /usr/local/rvm/scripts/rvm </syntaxhighlight> 8. Dê rvm list para ter certeza de que o rvm está instalado corretamente. Senão tiver, pode-se optar por fazer do passo 5 em diante, ou instalar o Ruby on Rails sem rvm (mas se optar por essa opção, saiba que a longo prazo ela é horrível). Instale o ruby: <syntaxhightlight lang="bash"> $ rvm install 1.9.3 $ rvm use 1.9.3 </syntaxhighlight> 9. Instale o postgresql:

$ sudo aptitude install libpq-dev
$ sudo apt-get install postgresql
$ sudo apt-get install postgresql-client

10. Finalmente, instale o jenkins:

$ wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
$ sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
$ sudo aptitude update
$ sudo aptitude install jenkins

11. Como dito no tutorial, o jenkins roda por padrão na porta 80. No caso, a dupla já tinha o Gitlab CE utilizando essa porta, então, como dito no tutorial, foi necessário fazer um reverseproxy com o nginx para a porta 8080. Primeiro, instale o nginx:

$ sudo apt-get install nginx
$ sudo /etc/init.d/nginx start

12. Abra o config file (utilizei o vim, mas pode ser utilizado o nano ou qualquer editor de texto presente na máquina):

$ sudo vim /etc/nginx/nginx.conf

13. Procure pelo block "server", e adicione o seguinte:

server {
    listen 80 default;
    server_name ipdoseuservidor;
    location /{
        proxy_pass http://ipdoseuservidor:8080;
        }
    }

14. Rode o serviço do jenkins:

$ sudo service jenkins start

15. Abra o jenkins via url:

ipdoseuservidor:8080

16. Vá em Manage Jenkins

17. Vá em Manage Plugins

18. Instale os plugins: Gitlab Hook, Git Plugin, ruby-runtime, Git Client Plugin. NÃO INSTALE: Gitlab Plugin. Ele está quebrado.

19. Crie um novo item, coloque freestyle

20. Selecione o git

21. Crie uma conta no gitlab para seu jenkins. Adicione um ssh nele, linke à conta do gitlab. Não utilize um ssh de deploy, ou você só poderá dar pull, e não poderá dar push.

22. Adicione seu ssh no projeto que você estava adicionando no item 19.

23. Coloque a url ssh do repositorio. No nosso caso foi: git@gitlab.com:UNB-GPPMDS-2014/Proconsulta.git

24. Selecione o pool SCM

25. Foi utilizado esse bash, é recomendado que também seja-o utilizado:

#!/bin/bash
$ source /usr/local/rvm/scripts/rvm
$ rm Gemfile.lock
$ git branch
$ bundle install --without production
$ rake db:create
$ rake db:test:prepare
$ rspec

26. Foi adicionado um post-build action de dar push na branch working_tree_gcs. Esse passo é opcional, mas interessante.

E assim acaba a configuração do Jenkins para utilização do Proconsulta, ou de um projeto com características similares.

Vagrant - Ambiente de Desenvolvimento

Na máquina em que o Vagrant foi configurado, executou-se o seguinte script:

#!/bin/bash
clear

echo "Atualizando sistema"
echo
sudo apt-get update -y
sudo apt-get upgrade -y

echo
echo "Instalando VirtualBox"
echo
echo 'deb http://download.virtualbox.org/virtualbox/debian trusty contrib' >> /etc/apt/sources.list
echo 'deb http://download.virtualbox.org/virtualbox/debian trusty non-free' >> /etc/apt/sources.list
wget -q https://www.virtualbox.org/download/oracle_vbox.asc -O- | sudo apt-key add -
sudo apt-get update -y
sudo apt-get install -y virtualbox-4.3

echo
echo "Instalando Vagrant"
echo
sudo apt-get install -y vagrant

echo
echo "Criação de aquivo base do Vagrant"
echo
mkdir vagrant
cd vagrant
vagrant init ubuntu/trusty64

Após ser gerado o arquivo base do Vagrant, editamos-o para refletir nossas necessidades:

# -*- mode: ruby -*-
# vi: set ft=ruby :
#
# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure(2) do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at
  # https://docs.vagrantup.com.
  #
  # Every Vagrant development environment requires a box. You can search for
  # boxes at https://atlas.hashicorp.com/search.
  config.vm.box = "ubuntu/trusty64"
  config.vm.box_url = "https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box"
  #
  # Disable automatic box update checking. If you disable this, then
  # boxes will only be checked for updates when the user runs
  # `vagrant box outdated`. This is not recommended.
  # config.vm.box_check_update = false
  #
  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine. In the example below,
  # accessing "localhost:8080" will access port 80 on the guest machine.
  config.vm.network :forwarded_port, guest: 3000, host: 3000    # rails
  #
  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  # config.vm.network "private_network", ip: "192.168.33.10"
  #
  # Create a public network, which generally matched to bridged network.
  # Bridged networks make the machine appear as another physical device on
  # your network.
  # config.vm.network "public_network"
  #
  # Share an additional folder to the guest VM. The first argument is
  # the path on the host to the actual folder. The second argument is
  # the path on the guest to mount the folder. And the optional third
  # argument is a set of non-required options.
  # config.vm.synced_folder "../data", "/vagrant_data"
  #
  # Provider-specific configuration so you can fine-tune various
  # backing providers for Vagrant. These expose provider-specific options.
  config.vm.provider "virtualbox" do |vb|
    # Customize the amount of memory on the VM:
    vb.memory = "512"
  end
  # View the documentation for the provider you are using for more
  # information on available options.
  #
  # Define a Vagrant Push strategy for pushing to Atlas. Other push strategies
  # such as FTP and Heroku are also available. See the documentation at
  # https://docs.vagrantup.com/v2/push/atlas.html for more information.
  # config.push.define "atlas" do |push|
  #   push.app = "YOUR_ATLAS_USERNAME/YOUR_APPLICATION_NAME"
  # end
  #
  # Enable provisioning with a shell script. Additional provisioners such as
  # Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the
  # documentation for more information about their specific syntax and use.
  # config.vm.provision "shell", inline: <<-SHELL
  #   sudo apt-get update
  config.vm.provision "shell", path: "script/vagrant_development.sh"
  #   sudo apt-get install -y apache2
  # SHELL

end

Como provisioners, utilizamos o shell, como mostrado no arquivo acima (nas ultimas linhas). Para tanto, criamos o script vagrant_development.sh dentro da pasta script do repositório. O script pode ser visto abaixo:

clear

echo "Instalando RVM com Ruby 2.2.0"
echo
gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
\curl -sSL https://get.rvm.io | bash -s stable --ruby=2.2
source /usr/local/rvm/scripts/rvm

echo
echo "Instalando GIT"
echo
sudo apt-get install -y git

echo
echo "Criando link simbólico da pasta compartilhada na pasta 'home' do Vagrant"
echo
ln -s /vagrant/ /home/vagrant/proconsulta

echo
echo "Indo para a branch rails4"
echo
cd proconsulta
git checkout -t origin/rails4
echo

echo
echo "Instalando dependências do Proconsulta"
echo
sudo apt-get install -y libpq-dev postgresql-9.3 nodejs

echo
echo "Configurando PostgreSQL"
echo
export DB_USER="vagrant"
export DB_PASSWORD="vagrant"
sudo su - postgres bash -c "psql -c \"CREATE USER vagrant WITH CREATEDB PASSWORD 'vagrant';\""

echo
echo "Instalando gems necessárias"
echo
rm Gemfile.lock
bundle

echo
echo "Criando banco de dados e realizando migrações"
echo
rake db:create
rake db:migrate

Com o script acima, é possível acessar o ambiente de desenvolvimento no repositório em que o Vagrantfile se encontra. Assim, o sistema está pronto para uso e pode ser executado tanto nativamente(no host) quanto via Vagrant, alterando-se sempre os mesmos arquivos. Optamos por essa abordagem por ela ser flexível e funcional para os diferentes perfis de desenvolvedores. Também foi criada uma box para VirtualBox disponível no servidor da HashiCorp, que pode ser mais interessante quando não se deseja instalar todas as dependências do projeto a cada vez que se executa o comando vagrant destroy. Caso deseje-se utilizar essa box, basta substituir as linhas:

config.vm.box = "ubuntu/trusty64"
config.vm.box_url = "https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box"

por:

# Necessário Vagrant >= 1.5 quando não se deseja usar "config.vm.box_url"
# "config.vm.box_url" não está disponível para a box edu-vital/proconsulta
config.vm.box = "edu-vital/proconsulta"

O repositório dessa box pode ser encontrado em: edu-vital/proconsulta.

Migração - Rails3.2.15 e Ruby1.9.3 para Rails4.2.0 e Ruby2.2.0

A base para a migração do rails3 para o rails4 foi a video-aula do Ryan Bates, da famosa série "Railscast". Link para a video-aula: http://railscasts.com/episodes/415-upgrading-to-rails-4?view=asciicast

Primeiramente, é necessário ressaltar que embora a video-aula seja excelente, ela é suficiente somente para softwares de contextos menores, como o caso do Proconsulta. Em casos de softwares muito escalados, a video-aula não cobre muitos pontos. Sobre a migração do Proconsulta em si, o grande problema ficou por conta do mass-assignment e o attr_acessible, que mudaram completamente no rails4 (por questões de segurança), além da questão de precompile de css e mudanças na síntaxe. Não poderá ser explanado as etapas pois foram diversas, mas as mudanças podem ser acompanhadas via branch "rails4", no repositório do Proconsulta. Mais especificamente, os seguintes commits resumiram o processo:

https://gitlab.com/UNB-GPPMDS-2014/Proconsulta/commit/17f2174df059e84f906a3b5d1adf824c85897c2f

https://gitlab.com/UNB-GPPMDS-2014/Proconsulta/commit/650aa365964f71e1becce30633866530fcf90ed7

https://gitlab.com/UNB-GPPMDS-2014/Proconsulta/commit/4a41014a3844a4565be806becb6a1276cef91944

https://gitlab.com/UNB-GPPMDS-2014/Proconsulta/commit/4b6249272b4346b6842f516e0dbeabfa88068096

Milestone

Os milestones trazem as datas dos incrementos que serão entregues durante o ciclo de produção. A disciplina de GCS já trás datas de apresentações, então as milestones serão orientadas a tais datas. Além disso, para um melhor tracking, no repositório do projeto será mostrado o andamento das issues, o que dará uma melhor visão sobre o que especificamente está sendo feito em cada milestone.

Milestone	Resultado Esperado (v0.0)	Data
PC1	Script que automatize o processo de build do Proconsulta, criação de serviço no DigitalOcean e configuração do deploy com o Capistrano	10/06
PC1	Integração continua funcionando com o DigitalOcean	17/06
Entrega final	Script que instala as dependencias do projeto e configuração de ambiente com o Vagrant	01/07

Recursos e Treinamentos

• Conhecimento básico em Ruby on Rails, banco de dados, controle de versão, e gerência de configuração.
• Ferramentas: Capistrano, Chef, Gitlab CE, Gitlab CI, Vagrant, DigitalOcean.

Referência

RUP. Configuration Management Plan. Rational Unified Process, 2002. Disponível em:http://sce.uhcl.edu/helm/rationalunifiedprocess/process/artifact/ar_cmpln.htm Acesso em: 04 de maio de 2015