SCT
Grupo: Gustavo Sabino e Kleber Brito
Introdução
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]Organização, Responsabilidades e Interfaces
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]O Travis-CI foi utilizado como ferramenta de integração continua e testes automatizados
Vagrant
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]O Capistrano é a ferramenta utilizada que cuidará do deploy automatizado do sistema no ambiente de produção
Heroku
[editar | editar código-fonte]É uma plataforma como serviço de nuvem, utilizado como servidor para hospedagem da aplicação.
Empacotamento Debian do Ruby
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]Controle de Configuração e mudança
[editar | editar código-fonte]Com o que iremos contribuir
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]Processo de Armazenamento de Mídia e Liberação do Projeto
[editar | editar código-fonte]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
[editar | editar código-fonte]Integração Contínua - Travis-CI
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]# 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
[editar | editar código-fonte]# 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
[editar | editar código-fonte]server '127.0.0.1:2222', user: 'user', roles: %w{web}
Verificando
[editar | editar código-fonte]- Digite cap production deploy para verificar se tudo está certo.
- O deploy é realizado ao digitar cap deploy
Hospedagem - Heroku
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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
[editar | editar código-fonte]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