SCT

Grupo: Gustavo Sabino e Kleber Brito

Introdução

Este documento tem como finalidade descrever o plano de gerência de configurações a ser aplicado no software SCT - Sistema de Clínicas terapêuticas. O SCT é um software criado para auxiliar o usuário na identificação de clínicas terapêuticas existentes em todo o Brasil, disponibilizadas através das informações presentes nos dados abertos do governo federal. O Software tem como objetivo auxiliar o combate as drogas, com campanhas de conscientização dos malefícios do seu uso, informações sobre clínicas para dependentes químicos existentes em todo o território nacional, quiz para saber se um determinado individuo é um possível usuário entre outras funcionalidades.

Visão geral

Esse plano de Gerenciamento de configuração de Software possui como diretrizes uma melhor organização e responsabilidade para o projeto, as ferramentas utilizadas, e por fim resultados da implantação do gerenciamento

Escopo

O escopo deste plano abrange:

• Integração contínua
• Controle de versão
• Ambiente virtual para desenvolvimento
• Empacotamento Debian do Ruby
• Automatização de tarefas
• Deploy automatizado
• Hospedagem na nuvem

Finalidade

Este plano tem como propósito guiar e especificar ações que resultem na melhoria dos processos de Gerência de Configuração do software SCT. Os métodos especificados aqui deverão ser implementados em aproximadamente 2 meses. O SCT é um software desenvolvido durante a disciplina de MDS em conjunto com GPP durante o período do 1º semestre de 2015.

Gerenciamento de configuração de software

Organização, Responsabilidades e Interfaces

A equipe é formada pelos alunos Kleber Brito e Gustavo Sabino. Ambos farão os mesmos papéis, todos os papéis previstos para uma Gerência de Configuração de Software, como gerente de controle mudanças, gerente de configuração. Além disso, toda a equipe participará da elaboração do Plano de Gerência de Configuração de Software, configurar o ambiente de gerência de configuração, atualizar Wiki, entre outros

Ferramentas, Ambiente e Infra-estrutura

Para executar a gerência de configuração, as seguintes ferramentas foram utilizadas:

Ferramentas de controle de versão

Ferramenta	Descrição
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.
GitHub	Repositório online que utiliza o Git para armazenamento do projeto

Travis-CI

O Travis-CI foi utilizado como ferramenta de integração continua e testes automatizados

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

Shell script

Processador de comandos que interage com os comandos do script do Unix. Foi utilizado na automatização de partes do projeto que eram repetitivas e necessárias, podendo dessa forma ser automatizada. Apresenta a vantagem de não ser necessária qualquer configuração (desde que o ambiente seja Unix).

Capistrano

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

Heroku

É uma plataforma como serviço de nuvem, utilizado como servidor para hospedagem da aplicação.

Empacotamento Debian do Ruby

Para a construção do projeto do SCT foi utilizado o ruby versão 2.3.1. No entanto para a instalação do mesmo é necessário instalar primeiramente o rvm e após isso instalar via terminal a versão específica do ruby desejada. Com o empacotamento .deb esse processo é facilitado, gerando o pacote ruby-stable_2.3.1-1_amd64.deb. Instalando a versão desejada do ruby, com as suas devidas dependências, apenas clicando com o botão direito e acionando a opção: "Install package".

Definições, Acrônimos e Abreviações

Abreviação	Definição
SCT	Sistema de Clínicas terapêuticas.
MDS	Método de Desenvolvimento de Software
GPP	Gestão de Projeto e Portfólio de Software
GCS	Gerência de Configuração de Software
IC	Integração Contínua

O programa de Gerência de configuração

Controle de Configuração e mudança

Com o que iremos contribuir

Atividades a serem desenvolvidas

• Integração contínua
• Criação de infra-estrutura padrão para o desenvolvimento
• Automatização de tarefas
• Deploy automatizado
• Hospedagem no servidor online

Processamento e Aprovação da Solicitação de Mudança

As mudanças são propostas ao projeto pelo recurso issue oferecido pela ferramenta de forge GitHub, onde o solicitante descreve a mudança. Com isso, as propostas são analisadas em termos de viabilidade de implantação, e se viáveis são aprovadas seguindo para o comitê de controle de mudança.

Comitê de Controle de Mudança

Comitê de controle de mudanças é composto pelos membros Kleber Brito e Gustavo Sabino. As mudanças são propostas ao projeto por meio de issues, quando já analisadas e aprovadas para serem executadas seguem para a equipe de implantação de controle de mudanças que deve priorizar as mudanças e riscos e executar as alterações respectivas.

Estimativa do Status de Configuração

Processo de Armazenamento de Mídia e Liberação do Projeto

O projeto deverá ser armazenado no GitHub e deve estar disponível em código aberto. A cada milestone cumprido, deve ser lançado uma nova release.

Relatório de Acompanhamento/Tutorial

Integração Contínua - Travis-CI

Primeiramente deve-se fazer o cadastro no site: https://travis-ci.com/ bastando logar-se com sua conta do GitHub e logo você cai na Dashboard, onde estão seus projetos listados em uma coluna à esquerda e o status detalhado do build do projeto selecionado.

Com o Travis habilitado para seu projeto, você pode ir até a página do projeto no GitHub e olhar as configurações do serviço, na aba Webhooks & Services, nela, você poderá ver o serviço habilitado.

É necessário configurar o arquivo: .travis.yml que é aonde fica as configurações necessárias para rodar os testes entre outros. No projeto do SCT ficou conforme mostrado abaixo:

language: ruby

script:
  - bundle exec rake db:migrate
  - bundle exec rake db:seed
  - bundle exec rake

rvm:
  - 2.1.0
notifications:
  email:
    recipients:
      - kleberbritomoreira10@gmail.com
      - kleber_kbm@hotmail.com
      - Gustavo.sabino@hotmail.com
    on_success: always  

after_success:
  - "bundle exec cap deploy"

Ambiente de Desenvolvimento - Vagrant

Vagrant.configure(2) do |config|

  config.vm.box = "debian/jessie64"

  config.vm.provider "virtualbox" do |v|
    v.memory = 1024
    v.cpus = 2
    v.name = "sct_vm"
  end
 

  config.vm.provision "shell", path: "script.sh" 
  

  config.vm.network "private_network", type: "dhcp"
  config.vm.network "forwarded_port", guest: 8000, host: 8080, auto_correct: true

end

Automatização - Shell script

O processo de rodar as migrações, dar bundle install, rodar o rspec, entre outros são repetidos diversas vezes durante a produção do SCT (e dos softwares em Ruby on Rails, no geral). Por tal motivo, sentiu-se a necessidade de automatização desses fluxos de comandos. E para tal foi utilizado shellscript, devido a sua implementação ser bem tranquila e corresponder as necessidades desejadas.

Para a criação dessa automatização, deve-se primeiramente criar um arquivo com extensão .sh. No projeto, por exemplo, foi criado um arquivo chamado script.sh

Para poder editar o arquivo , precisa ser concedido permissão de escrita. Dessa forma deve-se digitar no terminal:

$  chmod 777 script.sh    

O chmod é utilizado para setar permissões em arquivos e diretórios. O valor 777 concede todos os direitos (read, write, execute) para o usuário, o grupo e os outros. O script introduzido no arquivo script.sh foi:

#!/bin/bash

apt-get -y update
apt-get -y install 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

apt-add-repository -y ppa:brightbox/ruby-ng >/dev/null 2>&1
apt-get -y update >/dev/null 2>&1
apt-get -y install libgmp-dev
apt-get -y install 'development tools' build-essential

apt-get -y install rubygems

install Ruby ruby2.3 ruby2.3-dev

gem install bundler


curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -

gem install rails

apt-get install Git git
apt-get install -y Ruby ruby2.3 ruby2.3-dev

update-alternatives --set ruby /usr/bin/ruby2.3 >/dev/null 2>&1
update-alternatives --set gem /usr/bin/gem2.3 >/dev/null 2>&1

# rbenv install
# rbenv rehash

apt-get install -y libxml2 libxml2-dev libxslt1-dev

# apt-get -y install mysql-server mysql-client libmysqlclient-dev


# bundle install
# rake db:migrate
# rake db:seed
# rspec
# rails s

E para executar esse script com os comandos de automatização basta digitar no terminal:

$ ./NomeDoArquivo.sh

Empacotamento Debian

Primeiramente deve-se fazer a assinatura do pacote, ou seja, gerar a chave GPG. Observação: Quando aparecer $ é porque o comando a seguir deve ser digitado no terminal. Entre no terminal e digite os comandos:

$ sudo apt-get update

$ sudo apt-get -y upgrade

$ sudo apt-get -y install rng-tools 

Depois que o pacote foi instalado, execute o comando abaixo:

$ sudo rngd -r /dev/urandom 

Agora gere a chave GPG

$ gpg --gen-key 

O seguinte texto deve ser exibido no terminal, selecione ou preencha a opção desejada conforme for solicitado:

gpg (GnuPG) 1.4.11; Copyright (C) 2010 Free Software Foundation, Inc.

 This is free software: you are free to change and redistribute it. 

There is NO WARRANTY, to the extent permitted by law. 

gpg: directory `/home/vagrant/.gnupg' created 

gpg: new configuration file `/home/vagrant/.gnupg/gpg.conf' created

gpg: WARNING: options in `/home/vagrant/.gnupg/gpg.conf' are not yet active during this run 

gpg: keyring `/home/vagrant/.gnupg/secring.gpg' created

 gpg: keyring `/home/vagrant/.gnupg/pubring.gpg' created Please select what kind of key you want:

   (1) RSA and RSA (default)   (2) DSA and Elgamal   (3) DSA (sign only)   (4) RSA (sign only) Your selection? 

RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048)

 Requested keysize is 2048 bits Please specify how long the key should be valid. 

        0 = key does not expire      <n>  = key expires in n days      <n>w = key expires in n weeks 

     <n>m = key expires in n months      <n>y = key expires in n years Key is valid for? (0) 0 

Key does not expire at all Is this correct? (y/N) Y You need a user ID to identify your key; 

the software constructs the user ID from the Real Name, Comment and Email Address in this form:    

"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>" Real name: "Seu nome aqui" Email address: "Seu endereco de email aqui"

 Comment: You selected this USER-ID:    "Nome do usuário <email>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need

a Passphrase to protect your secret key. We need to generate a lot of random bytes. It is a good idea to perform some other 

action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number 

generator a better chance to gain enough entropy. ...........+++++ ......................+++++ 

We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse,

 utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.

 +++++ +++++ gpg: /home/vagrant/.gnupg/trustdb.gpg: trustdb created gpg: key 8CEE231C marked as ultimately trusted public and

 secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model 

gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u pub   2048R/8CEE231C 2012-07-27      Key fingerprint = 926C

 C20B F27D 554E 0E5D  3699 9DB7 CC09 8CEE 231C uid                  Nome do usuário <email> sub   2048R/36DD9698 2012-07-27

Crie um diretório chamado ruby-deb

$ cd /vagrant 

$ mkdir ruby-deb

 $ cd ruby-deb

Baixe o tarball do programa que você quer empacotar. No nosso caso, usamos o tarball:

http://ftp.ruby-lang.org/pub/ruby/ Versão: ruby-2.3.1.tar.gz

Depois que o download do tarball terminar extraia o arquivo.

Agora instale o pacote dh-make, que permite converter um diretório de código-fonte em uma estrutura válida de acordo com a Política do Debian

$ sudo apt-get -y install dh-make vim

Entre no diretório ruby-2.3.1-p286 e execute o comando dh_make. Isto irá gerar um diretório Debian. Este diretório funciona como um manifesto de como o seu pacote será gerado.

De todos os arquivos desse diretório, o mais importante é o arquivo debian/control. Ele define as dependências do pacote, versão, dentre outras informações. Edite-o conforme o exemplo abaixo:

Source: ruby 

Section: universe/ruby 

Priority: extra 

Maintainer: Seu nome <seu email> 

Build-Depends: debhelper (>= 8.0.0), autotools-dev, libssl-dev, libyaml-dev, libreadline6-dev, libffi-dev, zlib1g-dev 

Standards-Version: 3.9.2 

Homepage: http://ruby-lang.org 

Package: ruby-stable 

Architecture: i386 amd64 

Depends: ${shlibs:Depends}, ${misc:Depends}, libyaml-0-2, libssl1.0.0, libffi6, zlib1g 

Description: Interpreter of object-oriented scripting language Ruby, version 2.3.1 Ruby is the interpreted scripting language for quick and easy object-oriented programming.  It has many features to process text files and to do system management tasks (as in perl).  It is simple, straight-forward, and extensible.

O campo Build-Depends deve conter as dependências que seu código-fonte precisa para ser compilado. Já o campo Depends define quais as dependências que devem ser instaladas quando o pacote for instalado.

Edite o arquivo debian/changelog. Atualize este arquivo com as informações sobre as mudanças introduzidas por este pacote. Ele também deve ter o versionamento do pacote.

ruby (2.3.1-p286-1) precise; urgency=low 

 * Initial release -- Seu nome <seu email>  Wed, 17 Oct 2015 16:36:35 +0000

ATENÇÃO: O nome e e-mail que é colocado no arquivo debian/changelog devem ser exatamente os mesmos que foram adicionados na chave GPG.

Antes de gerar os pacotes, instale as dependências de compilação. São as mesmas adicionadas no campo Build-Depends.

$ sudo apt-get install -y debhelper devscripts autotools-dev libssl-dev libyaml-dev libreadline6-dev libffi-dev zlib1g-dev

Agora é a hora de gerar os pacotes. Como a versão 2.3.1 precisa de uma versão de Ruby para poder fazer a compilação, instale o pacote disponível no Ubuntu.

$ sudo apt-get -y install ruby2.3.1

Agora, gere o pacote:

$ debuild

Esse último passo é um pouco demorado, mas logo após o término o pacote .deb terá sido criado com a mesma arquitetura específicada.

Deploy Automatizado - Capistrano

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

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'

config/deploy.rb

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

set :application, 'SCT'
set :repo_url, 'git@github.com:kleberbritomoreira10/GCS---SCT.git'
set :scm, :git
set :branch, "master"
set :repo_url, 'https://github.com/kleberbritomoreira10/GCS---SCT.git'

config/deploy/production.rb

server '127.0.0.1:2222', user: 'user', roles: %w{web}

Verificando

• Digite cap production deploy para verificar se tudo está certo.
• O deploy é realizado ao digitar cap deploy

Hospedagem - Heroku

Na pasta do seu projeto, digite:

$  heroku create

Este comando definirá referências ao repositório remoto heroku.

Para o Heroku funcionar propriamente, o banco de dados default do Rails deve ser trocado. Modifique sua GemFile

de

gem 'sqlite3'

Para

gem 'pg'

Execute

bundle install

para instalar as dependências.

modifique o Arquivo config/database.yml para indicar a troca no db:

default: &default
  adapter: sqlite3

Para

default: &default
  adapter: postgresql

Se seu db possuir path's para arquivos arquivo.sqlite3 substitua-os por novos nomes

development:
  <<: *default
  database: db/development.sqlite3

Novo nome:

development:
  <<: *default
  database: db/development

Agora atualize seu db:

$ rake db:create
$ rake db:migrate

Após tudo isso,commite suas alterações para o remoto Heroku:

$ git add .
$ git commit -m "init"
# e dê push para o remoto
$ git push heroku master

Se tudo ocorrer bem, o deploy ocorrerá dentro de alguns minutos.

Após o Sucesso, o heroku dará um link de acesso à aplicação.

Deploy com Travis-CI

Instale o Travis

 gem install travis

Gere uma Chave criptografada. Este comando gerará uma string que servirá como chave de acesso. copie-a para estruturar o arquivo .travis.yml

 travis encrypt $(heroku auth:token)

Ou

 travis setup heroku

O comando acima já deixa o arquivo .travis.yml preparado para deploy.

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

deploy:
  api_key:
    secure: "SUA CHAVE CRIPTOGRAFADA AQUI"

Adicione a linha abaixo para que o deploy ocorra em todas as branches do repositório.

on: 
    all_branches: true

Ou caso queira uma branch específica:

on: "Nome da Branch"

Resultado final deve ser algo parecido com:

deploy:
  api_key:
    secure: "SUA CHAVE CRIPTOGRAFADA AQUI"
  on: "Nome da Branch"

Milestones

Será definida uma política de Milestones para que tenha-se pequenas entregas nas datas estabelecidas.

Descrição	Data
Escolha da ferramenta de integração contínua	04/05
Configuração do ambiente de integração contínua	07/05
Escolha da ferramenta de virtualização	11/05
Implantação da ferramenta de integração contínua	22/05
Andamento do Projeto (Ponto de Controle)	25/05
Implantação do empacotamento Debian na versão do Ruby	01/06
Escolha do ambiente de automação	08/06
Configuração do ambiente de automação	15/06
Configuração do deploy automatizado	22/06
Hospedagem no servidor online	28/06
Finalizar entrega	29/06

Treinamento e Recursos

Para cumprir as atividades de GCS, ocorrerão treinamentos e estudos. Os treinamentos serão as aulas ministradas na disciplina de Gerência de Configuração de Software na faculdade FGA. Os estudos serão realizados pelos membros do time ao longo do decorrer do projeto.

Referências

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

https://nandovieira.com.br/criando-pacotes-debian-assinados-com-gpg

Proconsulta#Ger.C3.AAncia de Configura.C3.A7.C3.A3o de Programa

http://www.devmedia.com.br/introducao-ao-shell-script-no-linux/25778