Chamada Parlamentar
Introdução
[editar | editar código-fonte]Este Plano de Gerenciamento de Configuração tem como objetivo auxiliar o projeto Chamada Parlamentar. Tal plano visa controlar as mudanças que ocorrerão durante o ciclo de vida do projeto e Almeja guiar os envolvidos no projeto para as boas práticas, manter a integridade do desenvolvimento e do projeto, e facilitar o controle de mudanças.
Finalidade
[editar | editar código-fonte]Este Plano de Gerenciamento de Configuração tem como finalidade ser a base para as decisões tomadas no projeto no que se diz respeito à gerência de configuração de software.
Escopo
[editar | editar código-fonte]O software Chamada Parlamentar é um webApp que se encontra em construção, e tem como objetivo verificar a presença dos parlamentares da câmara dos deputados o Software apenas utiliza o GitHub para o gerenciamento do controle de versão. O software não está integrado com nenhuma ferramenta de CI.. e não há analise estatica do código até o presente momento.
Definições,Acrônimos e Abreviações
[editar | editar código-fonte]Sigla | Descrição |
---|---|
CM | Gerência de Configuração (Management Configuration) |
CI | Integração Contínua (Continuous Integration) |
MVC | Modelo Vista Controle (Model-View-Controller) |
IDE | Ambiente de Desenvolvimento Integrado
(Integrated Development Environment) |
Estrutura do Repositório
O código fonte do projeto está organizado em apenas um repositório
Branches
A versão estável do projeto está localizada em uma branch chamada master. O surgimento de novas issues e funcionalidades implicam da criação de uma nova branch específica para a realização destas novas funcionalidades. Uma nova ramificação deve receber um nome simbólico de acordo com seu propósito.
Organização
[editar | editar código-fonte]Atividades a Serem desenvolvidas ao longo da disciplina de CM.
• Estabelecer politicas de CM
• Escrever Plano de CM
• Realizar auditoria e configuração
• Configurar o plano de CI
Ferramentas, ambiente e infra-estrutura
[editar | editar código-fonte]Ferramenta | Descrição |
---|---|
Git | Controle de versão de código |
gitlab | Forge que sera utilizado no gerenciamento do Software |
Sublime text | Editor de Texto |
Jenkins | Ferramenta de integração em processo de amadurecimento |
Sonar | Ferramenta de análise estática |
O git é uma ferramenta de controle de versão distribuído, possuindo forte suporte para desenvolvimento não-linear.
O Gitlab é um Forge para a ferramenta de controle de versão git, e também pode ser utilizada como ferramenta de gerenciamento de projetos open-source, possuindo suporte para quadro Kanban, wiki e e outras opções voltadas para equipes ágeis.
O Sublime text é um editor de texto e código fonte multiplataforma e a versão utilizada será a versão 3.
A escolha do Jenkins como ferramenta de integração deu-se pela quantidade de material disponível para estudo da ferramenta.
A escolha do Sonar como ferramenta de análise estática deu-se por ser integrável com jenkins
Identificação da Configuração
[editar | editar código-fonte]A arquitetura do projeto foi feita em MVC, com uma controller ”fake” que faz a ligação do da controller com a view que foi nomeada de JSFconnection, na src main tambem se encontram pacotes de exception, model, parse e de web service da câmara e foi criada uma pasta somente para testes e esta subdividida em pacotes como a src main e as classes estão nomeadas da mesma forma só que com uma terminação diferenciada para informar que são testes ex. TestDeputyControl
Marcos
[editar | editar código-fonte]O que se pretende obter é um CI funcionando, para atingir esses objetivos haverá esforços para automatizar as builds e fazer ela ser auto testável, para todo o commit para a baseline fazer uma nova build, para auxiliar nos envolvidos no projeto e para que eles possam ver os resultados e utilizar a ferramenta de analise estática (SONAR) após cada commit. Após o ser atingido os objetivos propostos o plano de CM deverá ser atualizado ou ao encontrar algum empecilho.
Acompanhamento
[editar | editar código-fonte]O projeto pode ser acompanhado pelo sistema de controle de versão GitHub pelo link ChamadaParlamentar
O gerenciamento do projeto pode ser acompanhado pelo ChamadaGitlab
O projeto foi dividido em duas Milestones:
1 - Conhecer e Implantar Jenkins
2 - Release 2
1- Conhecer e Implantar Jenkins
[editar | editar código-fonte]Essa primeira fase consiste em conhecer mais a respeito do Jenkins-ci sua instalação e configuração .
- Instalação do Jenkins CI
Instalação do Jenkins CI em um sistema Ubuntu/Debian, pode-se seguir o tutorial indicado no site do Jenkins , outra alternativa para instalar o jenkins é seguir os comandos no terminal.
wget http://pkg.jenkins-ci.org/debian/binary/jenkins_1.618_all.deb
Execute no terminal dentro da pasta onde foi baixado o Jenkins o comando.
java -jar jenkins.war --httpListenAddress=127.0.0.1 --httpPort=8080
*Caso a porta 80 já esteja em uso selecione outra porta ex: httpPort=8081
Logo em seguida acesse no seu browser o endereço.
http://localhost:8080
Caso apareça no browser o erro 404 assegure que o serviço do jenkins esteja rodando com o comando:
sudo service --status-all
Se o serviço estiver parado utilize o comando:
sudo service jenkins start
- Configuração do Jenkins CI
Na Sessão Tutoriais há detalhes de como configurar o Jenkins-CI
Instalação do Gitlab CE Ubuntu 14.04
[editar | editar código-fonte]Tutorial de instalação retirado do site
1- Instalação de suas Dependencias
sudo apt-get install curl openssh-server ca-certificates postfix
2- Adicionando o pacote e instalando o gitlab
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash sudo apt-get install gitlab-ce
3- Configurando e iniciando o gitlab
sudo gitlab-ctl reconfigure
4- Nome e Login
Username: root Password: 5iveL!fe
Instalação Vagrant
[editar | editar código-fonte]tutorial retirado do site
Baixe o instalador do seu sistema operacional no site do virtualbox
Logo após isso va a pagina do Vagrant e Baixe o Sistema Operacional.
Configurando o Vagrant
criei uma pasta de nome vagrant
na pasta de usuários e em seguida uma pasta guide
:
$ cd ~/
$ mkdir vagrant
$ mkdir vagrant/guide
$ cd vagrant/guide
Logo em seguida use o comando
$ vagrant init
Esse comando cria um arquivo chamado Vagrantfile
que é onde irão as configurações de nossa box.
Para criação do Seu ambiente virtual vagrant você deve utilizar os seguintes comandos
$ vagrant box add lucid32 http://files.vagrantup.com/lucid32.box $ vagrant init lucid32 $ vagrant up
logo após ter feito isso abra o VagrantFile e digite:
Vagrant::Config.run do |config|
|
para subir a box que foi criada utilize o comando vagrant up e logo depois o comando vagrantssh
2- Release 2
Release 2 Consistia em Conhecer novas ferramentas que se adequassem ao projeto, integrar a ferramenta Sonar ao Jenkins e a elaboração do Relatorio Final do Projeto mostrando analise,resultados e dificuldades.
Analise
[editar | editar código-fonte]O software Chamada Parlamentar havia muito pouco de Gerencia e Configuração, sendo assim foi proposto que se implementasse a gerencia e configuração com a utilização de ferramentas que auxiliassem e facilitassem o ambiente de desenvolvimento através da integração continua.
A principio por não ter conhecimento a respeito de gerenciamento e configuração, houve uma demora na ambientação com as ferramentas disponíveis no mercado, quais existiam, para que serviam e se elas se aplicavam ao projeto que iria ser gerenciado.
Após uma visão sobre as ferramentas foi visto que seriam utilizados como auxilio as seguintes ferramentas:
- github
- gitlab
- digital Ocean
- Jenkins
- Sonar
Github para o versionamento do código o Gitlab para gerência do projeto, Digital Ocean vm para hospedar as ferramentas dos projeto, o Jenkins-CI para integração continua e o Sonar como ferramenta de analise estática.
Github: já vinha sendo utilizado para o versionamento do código o que tornou praticamente nulo o esforço.
Gitlab: Não existia nenhuma familiaridade com o gitlab até o mesmo ser apresentado em uma das aulas de GCS, após ter o conhecimento desse gerenciador de projeto foi decidido a sua utilização por considerar o mesmo mais completo que o Redmine, pois nele há suporte para versionamento de código onde a principio voce pode também fazer a instalação do seu próprio servidor gitlab para poder hospedar seus projetos, no gitlab se encontra a documentação referente ao software Chamada Parlamentar link.
DigitalOcean: Não obtinha nenhum conhecimento a respeito dessa ferramenta nem como a mesma funcionava após ler mais sobre a ferramenta no próprio site obtive um certo entendimento sobre como a mesma funcionava.
Jenkins: Não havia conhecimento a respeito de como era o funcionamento da ferramenta até que a mesma foi apresentada em uma das palestras ministradas durante a matéria de GCS e após ver a aplicação da mesma vi que ela se encaixaria melhor no projeto do que o travis, pois a utilização da linguagem era java e já existia um pom o que facilitou na escolha da ferramenta, sem incluir os diversos plugins que são disponibilizados pela mesma ferramenta. após a busca sobre o funcionamento da ferramenta encontrei tutoriais que auxiliavam na configuração da mesma o que facilitou a integração continua.
Sonar: Assim como as outras ferramentas não obtinha nenhum conhecimento da mesma nem do seu funcionamento após buscas foi obtido um melhor entendimento do seu funcionamento.
Resultados
[editar | editar código-fonte]Github:: se mostrou um bom gerenciador de versionamento de código sem apresentar nenhum problema durante o projeto, com um bom material para estudo disponível na internet não houve nenhuma complicação com o mesmo.
Gitlab:: ótimo gerenciador de projeto se mostrou bastante completo, e auxiliou no gerenciamento de tarefas pois o mesmo conta com milestones, labels e conta com sua própria wiki dentro do projeto o que facilita e auxilia nas informações do mesmo e por também ser um gerenciador de código torna-se ainda mais completo, tornando o uso do github "desnecessario" pois pode-se fazer uma migração desses código para o gitlab e ter todo o acompanhamento do seu projeto em uma única plataforma. Dentro do Gitlab foram criadas duas Milestones 1 que era a respeito da primeira fase do projeto que consistia em conhecer e implantar o jenkins e a segunda que foi chamada de Release 2 que consistia em conhecer e ver a possivel implementação de outras ferramentas no projeto.
DigitalOcean: Obtive alguns problemas com a vm da DigitalOcean devido em parte a falta de conhecimento a respeito do funcionamento da mesma que já conta com algumas opções como a de já vir implementado o servidor gitlab, ao utilizar a mesma notei uma certa lentidão em alguns momentos o que dificultou sua utilização, também encontrei alguns problemas em relação ao jenkins na vm pois a mesma não conseguia segurar o processo de execução do jenkins, sendo assim tinha que iniciar o serviço do jenkins a cada 2 minutos o que tornou praticamente impossível a utilização do jenkins nessa vm que eu estava utilizando no Digital Ocean, as configurações da VM eram as seguintes:
- 512MB Ram
- 20GB SSD Disk
- Ubuntu 14.04 x64
Jenkins: O Jenkins-CI se mostrou uma ótima ferramenta de integração, a principio tive grande dificuldades em entender o funcionamento da mesma até achar alguns tutoriais que auxiliavam na configuração da ferramenta o que tornou o processo muito mais rápido e simplificado, apesar disso o jenkins é uma ferramenta um pouco complicada de se entender e configurar, mas a partir disso foi conseguido realizar alguns processos com o jenkins tais como:
- conectar o jenkins ao github.
- Automatização de Builds, a cada commit realizado na master no github uma nova build é gerada.
- rodar os testes unitarios atraves do maven.
- Build a partir da Tag do Github.
- Criação de Tags automatizadas no github.
Problemas com o Jenkins, ao tentar fazer a autenticação do jenkins utilizando o GitHub para autenticação o plugin que faz esse trabalho estava com problemas, e isso comprometeu todo o ambiente fazendo com que o ambiente do jenkins quebrasse, ao acessar o endereço local da aplicação a mesma era redirecionada para para uma pagina 404 do github, busquei soluções na internet em sites como stackoverflow não conseguindo achar nenhuma solução para o problema, tambem entrei em contato com a pessoa que ministrou a palestra sobre jenkins o mesmo tambem não tinha conhecimento a respeito da solução daquele problema, sendo assim tive que remover o jenkins da maquina, fazer o download, rodar o jenkins e fazer toda a configuração do projeto novamente o que levou a um gasto de tempo que não havia sido previsto gerando assim atraso no andamento do projeto.
Sonar
foi subido o sonar na maquina na qual eu estava trabalhando mas não obtive exito em executa-lo procurei tutoriais de como ele funcionava mas não consegui faze-lo funcionar ao tentar integra-lo com o jenkins o plugin que eu estava utilizando não funcionava como o esperado não apresentando nenhum resultado, então foi postergada essa parte do projeto.
Vagrant
Ao final do projeto tentei implementar o vagrant para fornecer um ambiente de desenvolvimento do mesmo, mas devido a falta de tempo devido a problemas com o jenkins não houve tempo para estudar a ferramenta devidamente e como funciona seu script, sendo feito assim apenas a sua instalação e levantamento de um box na maquina local.
Tutoriais
https://www.digitalocean.com/community/tutorials/how-to-manage-jenkins-with-rancher-on-ubuntu-14-04
http://blog.camilolopes.com.br/unit-test-jenkins-maven/
http://blog.camilolopes.com.br/serie-continuous-integration-criando-uma-tag-no-github-via-jenkin
http://blog.camilolopes.com.br/serie-continuous-integration-build-a-partir-da-tag-github/
http://www.abstraindo.com/ambiente-de-desenvolvimento/vagrant-de-forma-simples-parte-1/
https://about.gitlab.com/downloads/
Referencias
[editar | editar código-fonte]http://en.wikipedia.org/wiki/Continuous_integration