NovoSGA
Introdução
[editar | editar código-fonte]Finalidade
[editar | editar código-fonte]Esta página tem como finalidade definir um plano de gerência de configuração de software para especificar as atividades e ferramentas que serão usadas ao decorrer do processo de manutenção do software NovoSga.
Objetivo
[editar | editar código-fonte]O planejamento da gerência deste trabalho tem como proposta, a partir da análise e estudo do projeto, adicionar uma integração contínua(Travis), deploy automatizado e o Vagrant ou Docker.
Visão Geral
[editar | editar código-fonte]O NovoSga é uma plataforma de código aberto que permite grandes ou pequenas organizações gerenciarem o fluxo do atendimento, no site se encontra cada funcionalidade específica[1]. A plataforma possui vários projetos que unidos compõe todo seu escopo, no caso deste trabalho em questão o foco será no projeto principal, definido também como o novosga, possuindo os seguintes módulos de funcionalidades[2]:
- Triagem (emissão de senha)
- Monitor (gerenciamento)
- Atendimento
A aplicação web é escrita em PHP utilizando as melhores práticas de desenvolvimento[3].
- PHP 5.4 - 5.6
- HTML5
- CSS3
- Doctrine PHP 2.4
- jQuery 1.9
- Twitter Bootstrap 3
- Highcharts
Testado nos seguintes bancos:
- PostgreSQL
- MySQL
Repositórios
[editar | editar código-fonte]- O repositório original do projeto está disponível em https://github.com/novosga/novosga
- O repositório criado de um fork feito a partir do projeto original está disponível, junto com com os demais repositórios, na organização criada em https://github.com/GCS-Projects
Plano de Trabalho
[editar | editar código-fonte]Cronogramas
[editar | editar código-fonte]Inicialmente o cronograma foi criada para haver um longo tempo entre o término do projeto e sua apresentação final e isso foi um dos pontos mais positivos no projeto, pois por conta das dificuldades com a elaboração do script da integração contínua e na mudança de escopo (Trac para Deploy), houve atraso nas datas.
Cronograma Inicial
[editar | editar código-fonte]Data | Atividade | Situação |
---|---|---|
03/10 | Estudo da linguagem e análise das ferramentas. | Prosseguiu |
10/10 | Preparação e familiarização com ambiente de projeto. | Prosseguiu |
17/10 | Estudo da ferramenta de integração. | Atrasou |
19/10 | Realizar integração contínua. | Atrasou |
24/10 | Estudo da ferramenta (Vagrant/Docker). | Prosseguiu |
26/10 | Configuração do Vagrant ou Docker. | Prosseguiu |
31/10 | Estudo da ferramenta Trac + Git. | Mudou o escopo |
02/11 | Configuração do Trac. | Mudou o escopo |
07/11 | Ajustes finais do projeto. | Prorrogou |
15/11 | Preparar apresentação. | Prorrogou |
Cronograma Final
[editar | editar código-fonte]Data | Atividade | Situação |
---|---|---|
03/10 | Estudo da linguagem e análise das ferramentas. | F |
10/10 | Preparação e familiarização com ambiente de projeto. | F |
17/10 | Estudo da ferramenta de integração. | F |
19/10 | Realizar integração contínua. | AP |
24/10 | Estudo da ferramenta (Vagrant/Docker). | F |
26/11 | Configuração do Vagrant ou Docker. | F |
31/11 | Continuar integração contínua | AP¹ |
05/11 | Reavaliação de escopo | F |
12/11 | Estudo Deploy. | F |
14/11 | Realizar Deploy | F |
19/11 | Se AP¹, continuar integração contínua | F |
25/11 | Ajustes finais do projeto. | F |
27/11 | Preparar apresentação. | F |
F = Finalizado; AP = Atividade em processo ...
Gerenciamento de Configuração de Software
[editar | editar código-fonte]Papeis e Responsabilidades
[editar | editar código-fonte]Papel | Responsabilidade | Responsável |
---|---|---|
Gestor de configuração do projeto | Acompanha as alterações dos itens de configuração. | Guilherme |
Gestor de ferramentas de gerência de configuração de software | Mantém a infraestrutura necessária para a gerência de configuração. | Elmar e Guilherme |
Gestor de configuração de software | Aprova e gerencia as atividades. | Elmar |
Desenvolvedores | Desenvolvem os itens de configuração que serão gerenciados. | Elmar e Guilherme |
Ferramentas, Ambiente e Infra-estrutura
[editar | editar código-fonte]Ferramenta | Descrição |
---|---|
Git | Controle de versão. |
GitHub | Hospedagem do repositório. |
Travis[4] | Integração contínua. |
Vagrant[5]/Docker[6] | Virtualização de ambiente. |
Composer[7] | Gerenciamento de dependência do PHP. |
Doctrine | Framework de PHP para mapeamento objeto-relacional (ORM) |
Lamp ou Xampp | Ferramenta Apache para interpretar os códigos PHP. |
MySQL / PostgreSQL | Banco de dados. |
Como iremos contribuir
[editar | editar código-fonte]A instalação das dependências e ferramentas que serão usadas, se encontram nas referências da página.
Travis CI
[editar | editar código-fonte]O travis irá manter a estabilidade do projeto e realizar o monitoramento do desenvolvimento, realizando os builds dos arquivos enviados nas branches desejadas.
Pode-se depois expandir as validações usando os testes existentes no projeto.
Script
[editar | editar código-fonte]O script no formato YAML tem a função de direcionar o Travis CI a realizar atividades geralmente para o build e teste completo do sistema, no caso do php, como não existe build, é realizado o teste diretamente. Um processo de testes consiste de duas etapas principais: install, onde serão instaladas as principais dependêndias; script, onde executa o roteiro de construção. Tomando essas definições como base, foram inseridos os seguintes comandos abaixos para o script do projeto com suas respectivas necessidades.
language
, mostra qual será a linguagem do código testado.php
, é a parte que define quais versões da linguagem serão realizado os testes. No nosso projeto, o software suporta até a versão 5.6 do php.env
, local de definição de variáveis de ambientes que podem ser acessadas em qualquer momento no processo de teste, onde essas variáveis serão o ponto de definição para o uso dos banco de dados suportados no projeto em questão.before_install
, tópico em que é definido comandos a serem executados para a instalação das dependências adicionais requeridas pelo projeto, podendo estes ser pacotes ou serviços personalizados. No caso do novoSGA, é usado um serviço personalizado onde foram adicionados comandos para teste do bancos de dados em sequência, PostgreSQL e MySQL:- Se existir dados criados para o pgsql, reseta o banco.
- Cria o banco do pgsql para teste.
- Cria o banco do mysql para teste.
before_script
, onde são definidas ainda mais características do ambiente antes de executar o script, no caso roda-se comandos para atualizar e instalar o composer, que é onde está o resto das dependências para o projeto.script
, onde é executado o comando para teste do software.
Script novoSGA
[editar | editar código-fonte]language: php
php:
- '5.4'
- '5.5'
- '5.6'
env:
- DB=mysql
- DB=pgsql
before_install:
- sh -c "if [ '$DB' = 'pgsql' ]; then psql -c 'DROP DATABASE IF EXISTS test;' -U postgres; fi"
- sh -c "if [ '$DB' = 'pgsql' ]; then psql -c 'create database test;' -U postgres; fi"
- sh -c "if [ '$DB' = 'mysql' ]; then mysql -e 'create database IF NOT EXISTS test;' -uroot; fi"
before_script:
- composer self-update
- composer install
script:
- phpunit src/Novosga/Test/TestConectionDB_$DB.php
Obs: Pelo projeto não possuir nenhum teste implementado, foram criadas duas classes de teste de bancos de dados para uso do Travis CI.
Teste de Banco de Dados com MySQL
[editar | editar código-fonte]class TestConectionDB_mysql extends PHPUnit_Framework_TestCase {
public function testConectionWithDB() {
$conection = NULL;
$conection = mysqli_connect("localhost", "root", "", "test");
if (!$conection) {
$this->assertTrue(false);
} else {
mysqli_close($conection);
$this->assertTrue(true);
}
}
}
Teste de Banco de Dados com PostgreSQL
[editar | editar código-fonte]class TestConectionDB extends PHPUnit_Framework_TestCase {
public function testConectionWithDB() {
$conection = NULL;
$conection = pg_connect("host=localhost dbname=test user=postgres");
if ($conection) {
pg_close ($conection);
$this->assertTrue(true);
} else {
$this->assertTrue(false);
}
}
}
Vagrant/Docker
[editar | editar código-fonte]- Foi realizada uma pesquisa para selecionar a melhor ferramenta para o projeto.
- Ambas, Vagrant e Docker, poderiam solucionar o objetivo em realizar o desenvolvimento de um "container" para o projeto, onde dentro desse "container" haverá todas as características necessárias para o funcionamento e desenvolvimento do sistema, com configurações, processos, etc, que pudessem atender facilmente à necessidade de melhorar a colaboração de outras pessoas.
- Porém decidimos por escolher o Docker, devido a sua baixa necessidade de hardware, possibilitando o uso da mesma em máquinas com baixos recursos, difundindo o desenvolvimento independente dos fatores físicos.
Passos para instalação/funcionamento completo do docker para o novoSGA Observações:
- É interessante seguir à risca todos os passos apresentados a seguir para manter o funcionamento completo do processo. Caso queira mudar o link das pastas do novoSGA do host com o container, é necessário fazer alterações no docker-compose.yml (Linha 8) e nos comandos do passo 11, antes de executar o processo todo.
- Após os passos todos, existirá uma pasta chamada "novosga" clonada dentro de outra pasta chamada "novosgaDocker", é essa a sua ligação entre o Host e o Container. É nessa pasta, "novosga", que deverão ser feitas as mudanças e contribuições para o projeto. O Docker irá linkar automaticamente todas as mudanças feitas ali, para dentro do container.
Vamos aos passos para executar os containers de desenvolvimento para o NovoSGA com o Docker:
- 1. Instalar o Docker [8] no seu SO;
- 2. Instalar o Docker Compose [9], dependendo do SO, ele já vem instalado com a instalação do Docker;
- 3. Clonar o repositório do GitHub contendo o dockerfile e o docker-compose file;
- 4. Clonar também o repositório do novoSGA no GitHub ou GitHub Oficial, dentro da pasta do novosgaDocker clonado no item 3;
- 5. Acessar via terminal a pasta do novosgaDocker;
- 6. Executar o comando:
docker-compose up -d
(-d é uma tag para manter em segundo plano a execução dos container após a conclusão do "up");
Agora é necessário fornecer permissões para a pasta do novoSGA copiada para dentro do container:
- 7. Executar o comando:
docker-compose ps
- 8. Aparecerá 2 container, um referente ao Banco de Dados (db), e outro específico do novoSGA;
- 9. Identificar o nome do container do novoSGA;
- 10. Agora é necessário executar os comandos:
docker exec nome_do_container chown www-data:www-data /var/www/html/novosga/
docker exec nome_do_container chmod 777 /var/www/html/novosga/var/
docker exec nome_do_container chmod 777 /var/www/html/novosga/config/
docker exec nome_do_container a2enmod rewrite
docker exec nome_do_container service apache2 restart
# Necessário executar novamente o container após o restart do apache
docker-compose up -d
Agora, com as permissões concluídas, é preciso executar um comando para instalar as dependências do projeto novoSGA para funcionar corretamente.
- 11. Para isso digite o comando:
docker exec -i nome_do_container bash -c "cd novosga/ && composer install"
Após a conclusão do composer install, o sistema estará disponível para acesso pelo navegador.
- 12. Para acessar o container, é necessário saber qual IP aponta para o container, executando o comando:
docker exec nome_do_container cat /etc/hosts
- 13. O IP que em sua descrição conter números identificadores, é o IP de uso para acesso ao navegador;
- 14. Agora é só digitar o IP no navegador, seguido de /novosga/public
IP_DO_CONTAINER/novosga/public
Assim você terá acesso ao sistema do novoSGA.
- No primeiro acesso ao sistema, será necessário fazer a instalação do mesmo, que irá configurar perfil administrador de login, acesso ao banco de dados e outras informações necessárias, para isso é só seguir apresentados no próprio site, com algumas informações listadas a seguir:
- Banco de dados MySQL/MariaDB
- Host do banco de dados: IP com descrição de db quando digitado o comando do passo 12
- Porta: 3306
- Usuário do banco de dados: root
- Senha do banco de dados: phprs
- Nome da base de dados: phprs
Deploy Automatizado
[editar | editar código-fonte]O deploy automatizado foi configurado para ser realizado em um servidor particular, devido ao fato de não termos acesso ao servidor oficial do NovoSGA.
Este servidor, disponibiliza acesso via SSH, possibilitando assim configurar scripts de dependência nos momentos necessários para os updates realizados.
Para isso, usamos um repositório do tipo "bare" no servidor, que guarda apenas as informações atuais do repositório. Dentro do servidor, configuramos o arquivo "post-receive", localizado dentro da pasta de hooks do repositório. Este arquivo contém as informações:
GIT_WORK_TREE=/home/inter248/public_html/novosga git checkout -f
cd /home/inter248/public_html/novosga
php compose.phar install
Onde o primeiro comando resulta em atualização dos arquivos e pastas quando recebe update do repositório, no local estipulado no comando.
Após isso, é alterado o local acessado no momento para então executar o composer.phar install
, para instalar ou atualizar
as dependências para o software funcionar corretamente.
Para enviar alguma alteração para o repositório, foi criado um novo apontamento de repositório na máquina local, usando o comando
git remote add deploy link_de_atualização
Assim, sempre quando se achar necessário a atualização do projeto no servidor, basta dar um push nesse repositório deploy criado, usando
git push deploy master
Escolhemos fazer o deploy automaizado dessa maneira, evitando que em todos os momentos que o repositório no GitHub é atualizado,
atualize automaticamente o servidor de hospedagem, evitando atulizações desnecessárias e em momentos inoportunos do dia,
possibiltiando assim o total uso do servidor sem problemas com as atualizações.
Obs: Link do NovoSGA no Servidor Particular.
Conclusão
[editar | editar código-fonte]Para concluir o trabalho realizado, é interessante comentar sobre a facilidade e agilidade na gerência do projeto, obtida com todos os recursos aprendidos e aplicados no projeto em questão.
- Com um Vagrant ou Docker, é possível agilizar o processo de configuração de ambiente de desenvolvimento, indo direto no processo de colaboração sem perder tempo arrumando a máquina pessoal com configurações que podem muitas vezes gerar conflitos com outras configurações já existentes no computador.
- Com o Jenkins ou Travis, é possível automatizar os builds e a execução de testes criados e existentes dentro do projeto, facilitando
a validação das funcionalidades do software, podendo assim então, encaminhar o trabalho para o deploy em um servidor.
- Por fim, o deploy automatizado, agiliza e facilita ao extremo o envio dos arquivos atualizados ao servidor. Os integrantes do grupo tem experiências com deploys, e de fato, manualmente é possível ocorrer erros de envio entre as pastas. Assim, existe também o ganho de velocidade no processo, automatizando comandos de updates dentro do servidor.
Referências
[editar | editar código-fonte]http://www.doctrine-project.org/
https://www.webdevbr.com.br/deploy-automatico-com-github-e-php