SiGA

Estudantes: Vinícius Carvalho e Vinícius Pinheiro

Contexto: Gerência de Configuração de Software

Introdução

SiGA significa Sistema Integrado de Gestão Acadêmica (Integrated Academic Management), que é um sistema que controla questões acadêmicas e financeiras de um instituto educacional.

Esse documento descreve o Plano de Gerenciamento de Configuração do software SiGA, desenvolvido na disciplina de Gerência de Configuração de Software (GCS) na Universidade de Brasília - Campus Gama.

Visão Geral

Esse plano de Gerenciamento de Configuração de Software possui como diretrizes uma organização em responsabilidades do projeto, modelo de GCS e as respectivas ferramentas utilizadas, e por fim resultados da implantação do gerenciamento.

Finalidade

A implantação desse plano tem por finalidade diminuir as ocorrências de problemas na configuração do da aplicação em outros ambientes, além de garantir maior qualidade no desenvolvimento de testes da aplicação, assegurando que as entregas de software aceitas estejam no nível aceitável definido pela equipe de gerencia e configuração.

Escopo

O estabelecimento do plano de configuração de software tem por escopo inserir ferramenta de controle da instalação da aplicação SiGA, preparar ambiente de desenvolvimento de testes unitários, integrar ferramenta de controle de testes e por fim relatar os resultados da implantação da gerência de configuração de software. Para isso, devem ser seguidas diretrizes apresentadas em tópicos pelo plano de gerência.

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

Termo	Significado
GCS	Gerência de Configuração de Software
Build	Versão do software composto por um ou mais itens de configuração
Baseline	É um marco a partir da entrega de um ou mais itens de configuração
Issue	Alguma funcionalidade/problema a ser entregue
Milestone	Marco do Projeto
SiGA	Software tratado por este documento. Sistema Integrado de Gestão Acadêmica. Disponível em: https://github.com/Sistema-Integrado-Gestao-Academica/SiGA

A aplicação SiGA

Funcionalidades da aplicação

Funcionalidade	Característica
Secretaria Acadêmica	Gerenciamento dos programas de pós-graduação
	Gerenciamento de cursos
	Gerenciamento das matrículas dos alunos
	Plano orçamentário
	Lista de oferta das disciplinas

Gerenciamento da Configuração de Software

Organização, Responsabilidade e Interfaces

Para realizar as atividades de Gerência de Configuração, os seguintes papéis e responsabilidades foram definidos:

Papel	Responsabilidade	Responsáveis
Gerente de Configuração	Estabelecer políticas de CM, Configurar ambiente de CM, Escrever plano de CM, Realizar auditoria de configuração, Relatar status de configuração.	Vinícius Carvalho Vinícius Pinheiro
Desenvolvedores	Analisa e cria os itens de configuração no código fonte	Emilie Moraes Ítalo Paiva Macário Soares Rodrigo Gonçalves Fillipe Feitosa

Ferramentas, Ambiente e Infra-estrutura

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

Ferramentas de Controle de Versão

Ferramenta	Descrição
Git	Sistema de controle de versão distribuído e gerenciamento de código fonte
GitHub	Serviço web hosting compartilhado que usa a ferramenta de versionamento Git

Ferramentas para Gerência de Configuração

Ferramenta	Descrição
Vagrant	Ferramenta de criação de ambiente de virtualização
Puppet	Ferramenta declarativa personalizada para descrever a configuração de sistemas, simplificando a tarefa de configuração e manutenção de servidores. Descreve recursos do sistema e seu estado.
Travis CI	Serviço de integração contínua distribuído usado para construir e desenvolver software

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 desenvolvimento

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

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.

Repositório GCS: https://github.com/Gerencia-de-Configuracao-Software/SiGA (Branch: GCS)

Cronograma

Semana	Período	Atividade
Semana 1	20/04 - 26/04	Levantar ferramentas, Definir cronograma e criar plano de GCS
Semana 2	27/04 – 03/05	Estudo de ferramentas e forma de trabalho
Semana 3	04/05 – 10/05	Estudo de ferramentas e forma de trabalho
Semana 4	11/05 – 17/05	Criação de maquina virtual usando o Vagrant
Semana 5	18/05 – 24/05	Criação de maquina virtual usando o Vagrant
Semana 6	25/05 – 31/05	Utilização da Ferramenta Puppet
PC1	01/06	Ponto de Controle do projeto
Semana 7	01/06 – 07/06	Estudo e melhoria do uso da ferramenta Puppet
Semana 8	08/06 - 14/06	Estudo da ferramenta de Integração Contínua
Semana 9	15/06 - 21/06	Implementar Integração Contínua
Semana 10	22/06 - 28/06	Implementar Integração Contínua
Semana 11	29/06 - 05/07	Implementar Integração Contínua
Entrega	06/07	Apresentação de Trabalho realizado

Vagrant

O Vagrant é uma ferramenta para a construção de ambientes de desenvolvimento completo, permite a criação rápida de ambientes virtuais auxiliando a criação da infraestrutura para a realização de testes, desenvolvimento ou provisionamento de ambientes utilizando uma das soluções de virtualização mais comuns, o Virtualbox, no caso desse trabalho.

Instalações necessárias

• Vagrant: https://www.vagrantup.com/downloads.html.
• Virtualbox: https://www.virtualbox.org/wiki/Downloads

Instalação da Box

1. Depois de criar o diretório, criamos o arquivo de configuração Vagrantfile.

$  touch Vagrantfile

2. Veja que o Vagrant criou um arquivo de configuração em nosso diretório, vamos verificar esse arquivo.

$ cat Vagrantfile

3. Confirgurando esse arquivo de configuração, temos:

 
# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!

# Versão do vagrant a ser usada
VAGRANTFILE_API_VERSION = "2"

# Iniciando a configuração do vagrant
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  # Define o nome da box a ser utilizada
  config.vm.box = "siga"
  # Define a url com a localização da box que será utilizada
  config.vm.box_url = "https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box"
  
  # Define ip statico da maquina virtual
  config.vm.network :private_network, ip: "192.168.2.15"
  # Define a localização da pasta que será sincronizada entre a raiz do vagrant e a maquina virtual
  config.vm.synced_folder "./", "/vagrant"
  
  # Define a ferramenta que irá prover as configurações, no caso, o puppet 
  config.vm.provision :puppet do |puppet|
    # Define o caminho da pasta com os manifests 
	puppet.manifests_path = "puppet/manifests"
	# Ativar o relatório detalhado
    puppet.options = ['--verbose']
    # Define o caminho da pasta com os módulos
  	puppet.module_path = "puppet/modules"
  end

4. Para iniciar a máquina virtual Ubuntu 12.04 LTS 64-bit, digitamos no terminal:

$  vagrant up --provider=virtualbox

5. Para entrar na box via ssh, digite no terminal:

$ vagrant ssh

Principais comandos

1. Inicia a máquina virtual mantendo-a no virtualbox

$  vagrant up --provider=virtualbox

2. O vagrant provision atualiza a box com os scripts do puppet.

$ vagrant provision

3. Agora para acessarmos o SiGA colocamos o endereço IP disponível na arquivo VagrantFile na url do browser.

http://192.168.2.15/html/SiGA/index.php

3. Para encerrar a box, digite no terminal:

$ vagrant halt

4. Para entrar na box via ssh, digite no terminal:

$ vagrant ssh

• Caso queira destruir a máquina virtual criada, utilize o vagrant destroy que remove todos os traços do ambiente de desenvolvimento .

$ vagrant destroy

Puppet

É uma ferramenta livre que usa uma linguagem declarativa para configurar sistemas operacionais. Ele automatiza o processo de entrega de software, permitindo o provisionamento de máquinas físicas ou virtuais, a orquestração, a emissão de relatórios, ou ainda a distribuição de códigos em fase inicial de desenvolvimento, testes, lançamentos ou atualizações.

A automatização da instalação de pacotes foi realizada através do provisionador Puppet, os comandos deste provisionador são escritos em arquivos chamados manifests, com uma linguagem baseada no Ruby. O manifest utilizado no projeto está exemplificado a seguir, nele é executado um update do sistema e são instaladas as seguintes dependências: Apache, Git, PHP, MySQL, entre outros, de acordo com o Manual de instalação do ambiente SiGA, além do git, usado para versionamento do código do projeto.

# Abrir esses diretórios
Exec { path => [ "/bin/", "/sbin/" , "/usr/bin/", "/usr/sbin/" ] }

# Incluindo as classes criadas no puppet
include migrate
include apache
include git
include php
include mysql
include libapache2
include php5_mcrypt
include phpmyadmin
include system-update

Acima temos o conceito de definir, que significa a escrita no arquivo Manifest. Porém também necessitamos executar o código declarado no arquivo Manifest, ou seja aplicar a configuração descrita. Para isso, contamos com a declaração de classes.

#Executa o update no sistema
class system-update {
  exec { 'apt-get update':
    command => 'apt-get update',
  }

  $sysPackages = [ "build-essential" ]
  package { $sysPackages:
    ensure => "installed",
    require => Exec['apt-get update'],
  }
}

#Executa a instalação do php
class php {

  package { "php5":
    ensure  => present,
    require => Class["system-update"],
  }
}

class libapache2 {

  package { "libapache2-mod-php5":
    ensure  => present,
    require => Class["system-update"],
  }
}

class php5_mcrypt{
   package { "php5-mcrypt":
    ensure  => present,
    require => Class["system-update"],

  }
}

#Executa a instalação do MySQL e do phpmyadmin 
class mysql { 
    package { "mysql-server": 
       ensure => present, 
       require => Class["system-update"], 
    } 
} 

class phpmyadmin { 
    package { "phpmyadmin": 
       ensure => present, 
       require => Class["system-update"], 
    } 
        exec{ 'echo "Include /etc/phpmyadmin/apache.conf" >> /etc/apache2/apache2.conf': 
        command => 'echo "Include /etc/phpmyadmin/apache.conf" >> /etc/apache2/apache2.conf', 
        require => Package['apache2'], 
        } 

        exec{ 'cp /vagrant/config.inc.php /etc/phpmyadmin/config.inc.php': 
        command => 'cp /vagrant/config.inc.php /etc/phpmyadmin/config.inc.php', 
        notify => Service['apache2'], 
        require => Package['phpmyadmin'], 
        } 

        exec{ 'mysql -u root < /vagrant/database.sql': 
        command => 'mysql -u root < /vagrant/database.sql', 
        require => Package['mysql-server'], 
        } 

}

#Executa a instalação do Git
class git {

  package { "git":
    ensure  => present,
    require => Class["system-update"],
  }

}

#Executa a instalação do Migrate
class migrate{

	exec{ '/usr/bin/php -f /vagrant/www/SiGA/index.php migrate':
	command => '/usr/bin/php -f /vagrant/www/SiGA/index.php migrate',
	require => Package['phpmyadmin'],
	}
}

O puppet na declaração de suas classes tem alguns comandos que podem ser utilizados, os usados aqui foram o exec{}(executa shell code), o package{}(gerencia pacotes), file{}(gerencia arquivos) e service{}(gerencia serviços)

Subcomandos utilizados

comando{'comando a ser executado':
    #Todos não são obrigatórios:

       #Comando a ser executado
       command => 'comando a ser executado',
    
       #Solicita que um pacote esteja presente
       require => Package['nome do servico'],

       #Solicita que uma classe tenha sido executada
       require => Class['nome da classe'],

       #Envia uma notificação à um serviço
       notify => Service["servico"],

       #Aponta o local da execução
       target => '/bin/bash',

       #Aponta o status desejado (present = presente no sistema)
       ensure => present,

}

TravisCI

O Travis CI proporciona um ambiente de build padrão e um conjunto padrão de etapas para cada linguagem de programação. É possível personalizar qualquer passo neste processo através do arquivo .travis.yml. O Travis CI usa o arquivo .travis.yml na raiz do repositório para tomar conhecimento sobre o projeto e como a build deve ser executada. O travis.yml pode ser escrito de forma minimalista ou detalhado. Alguns exemplos de que tipo de informação o arquivo .travis.yml pode ter:

• Que linguagem de programação o projeto usa;
• Quais comandos ou scripts devem ser executados antes de cada compilação (por exemplo, para instalar ou clonar as dependências do projeto);
• Qual comando é usado para executar o conjunto de testes.

Motivação

As principais motivações para a escolha do Travis CI foram:

• Ele é gratuito para repositórios públicos;
• Ser um serviço de Integração Contínua na nuvem que pode ser conectado a repositórios no GitHub;
• Notifica o usuário (por e-mail) sobre resultados da build;
• Vasta documentação;
• Rápida curva de aprendizado.

Passo-a-passo

1. Registre-se no Travis CI usando a conta do GitHub para que o Travis CI se sincronize com seus repositórios;
2. Acesse a página https://travis-ci.org/profile/;
3. Selecione o repositório em que deseja realizar a build;
4. Adicione um arquivo .travis.yml ao repositório. Este arquivo contém as informações sobre como realizar a build. É preciso commitar e dar push para que o Travis CI realize o build;

# Definição da linguagem
language: php

# Lista de qualquer versão do PHP que você quer testar.
php:
  - 7.0
  - 5.6
  - nightly

# Opcionalmente configurar exclutions e permitiu falhas na matriz
matrix:
  allow_failures:
    - php: nightly

# Cada comando no script é como um comando no terminal.
script: phpunit ./www/SiGA/test.php

1. Acesse classe de teste.php para verificar a classe de teste em que são acessados os arquivos no repositório.
2. Acesse https://travis-ci.org/ para acompanhar o status do build.

Referências

https://en.wikipedia.org/wiki/Travis_CI

https://www.vagrantup.com/docs/

https://docs.puppet.com/

http://junit.org/junit4/