Akan
Introdução
[editar | editar código-fonte]A gerência de configuração de software é uma atividade abrangente que é aplicada em todo o processo de engenharia de software. Uma vez que as mudanças podem ocorrer a qualquer tempo, as atividades da GCO são desenvolvidas para estabelecer baselines do projeto, identificar mudanças.
- controlar a mudança
- garantir que a mudança esteja sendo adequadamente implementada
- relatar a mudança às outras pessoas que possam ter interesse nela.
Neste plano apresentaremos as atividades e procedimentos a serem adotados pela gerência de configuração durante o projeto de construção, manutenção e evolução do aplicativo AKAN.
Objetivos
[editar | editar código-fonte]Este plano tem como objetivo definir as atividades e procedimentos da gerência de configuração, de forma a permitir que se tenha um maior controle das mudanças que venham a ocorrer no projeto durante todo o processo, inclusive da mudança de requisitos.
Público alvo
[editar | editar código-fonte]Este documento destina-se à possíveis futuros contribuidores no desenvolvimento do aplicativo Akan , de maneira que fique claro os procedimentos, configuração e ferramentas adotados para a manutenibilidade do mesmo .
Escopo
[editar | editar código-fonte]Este plano visa descrever os procedimentos bem como ferramentas que serão implementadas pela equipe de gestão e configuração a fim de tornar o aplicativo akan manutenível pela comunidade de software livre , será apresentado também um breve planejamento das etapas aos quais tais ferramentas e procedimentos serão executados.
O programa de Gerenciamento e Configuração
[editar | editar código-fonte]Métodos de Identificação
[editar | editar código-fonte]Todos os itens de configuração com exceção dos itens referente ao ambiente de desenvolvimento serão identificados por rótulos de identificação únicos. A versão dos documentos deverá estar contida no cabeçalho de cada documento, portanto a cada baseline gerada, a versão dos documentos da linha base deverá ser alterada. O modelo da nomenclatura encontra-se a seguir:
[Sigla do sistema]_[Sigla do Item]_[Data]_[Versão]
[Sigla do Sistema] - Sigla utilizada para representar o nome do sistema
[Sigla do Item] – Sigla correspondente ao nome do item de configuração
[Data] - Data no modelo AAAAMMDD
[Versão] - Versão do item
Exemplo:
AKAN_PGCO_20150506_1
Ferramentas , Ambiente e Infra-Estrutura
[editar | editar código-fonte]Ferramenta | Tipo | Descrição | Versão |
---|---|---|---|
Jenkins | Integração Contínua | Ferramenta responsável pela integração de testes funcionais automatizados com o repositório ao qual o código está hospedado. | 1.585 |
Git | Controle de versão | Sistema responsável pelo controle de versão do código. | 1.9.1 |
Vagrant | Ambiente de desenvolvimento | Ferramenta responsável por virtualizar o ambiente de desenvolvimento | 1.7.2 |
Maven | Build | Ferramenta responsável por gerar o build da aplicação | 3.3.3 |
Junit | Teste | Ferramenta responsável por efetuar a automação de testes | 3 |
Waffle.io | Gerenciamento de Projeto | Ferramenta responsável pelo gerenciamento do projeto através de Issues do Github | - |
Robotium | Teste | Ferramenta responsável pela automação de testes funcionais | 5.3.1 |
Contribuições
[editar | editar código-fonte]O que já está implementado
[editar | editar código-fonte]O projeto encontra-se atualmente parado , mas no período ao qual estava sendo desenvolvido ativamente fora implementada uma ferramenta de integração contínua (Jenkins) ao qual efetuava “merges” automáticos em uma branch de desenvolvimento quando alguma modificação era submetida ao repositório. Entretanto , não fora utilizado os principais recursos do jenkins tais como build automatizadas e geração de relatórios com cobertura de testes.
Com o que iremos contribuir
[editar | editar código-fonte]Para que seja possível a criação de um ambiente de integração que garanta a aplicação de boas práticas de produção de software neste projeto, é importante determinar quais serão as atividades desenvolvidas dentro do projeto para a aplicação das ferramentas descritas posteriormente.
Atividades a serem desenvolvidas:
- Integração contínua
- Criação de infra-estrutura padrão para desenvolvimento
- Cobertura de testes unitários e funcionais
Integração Contínua
[editar | editar código-fonte]Integração contínua é uma prática de metodologia ágil diretamente ligada ao XP (eXtreme Programming). A integração continua visa garantir que, qualquer alteração no código fonte seja rapidamente integrada e validada dentro da solução completa de forma transparente e automatizada. Caso uma alteração que tenha sido integrada acabe por gerar uma falha, o processo de integração continua deve garantir que o feedback seja imediato e preciso. Diante disso , para esse projeto será utilizado o Jenkins como ferramenta responsável pela integração contínua.
O Jenkis possibilita:
- Builds periódicos
- Testes automatizados
- Builds em ambiente diferentes do desenvolvedor
- Analise de código
- Customização do processo de integração
Infra-Estrutura padrão para desenvolvimento
[editar | editar código-fonte]Uma dificuldade corriqueira durante o início do processo de desenvolvimento ou ao iniciar o suporte a uma aplicação nova é a configuração do ambiente. Por diversas vezes a equipe gasta tempo demasiado para alinhar o ambiente de trabalho com as necessidades requeridas pelo projeto. No intuito de minimizar este esforço será adotada a ferramenta Vagrant.Com essa ferramenta é possível criar e configurar uma máquina virtual deixando-a pronto para a utilização em um projeto específico. Por se tratar de uma máquina virtual de tamanho reduzido e facilmente portável, é possível criar máquinas virtais para cada projeto em que esta sendo trabalhado e compartilha-las facilmente.
Cobertura de testes
[editar | editar código-fonte]A prática de criar testes unitários e funcionais é uma poderosa ferramenta para solucionar problemas como a alta taxa de defeitos, e a deterioração do sistema, seja por refatorações ou inserção de novas funcionalidades. Todavia, é necessário saber a abrangência dos testes criados, para isso é realizado a análise da cobertura dos testes.A cobertura de testes proporciona uma visão de quanto do código está assegurado por testes. No AKAN a proposta é implementar esta cobertura utilizando a ferramenta EMMA e integra-la ao Jenkins.
Ferramenta de Gestão
[editar | editar código-fonte]A visibilidade do processo tem sua importância no acompanhamento do projeto como um todo, permitindo verificar o andamento e os gargalos. Também é essencial para explicitar as atividades que estão sendo desenvolvidas e se as mesmas estão de acordo com o planejado.
Utilizando waffle.io será implementado uma metodologia de gestão, no intuito de proporcionar maior visibilidade para as ações que estão sendo executadas no projeto. Esta ferramenta, por meio de um quadro kanban, proporcionará visibilidade das demandas e issues em desenvolvimento, assim como permitirá acompanha-las no decorrer do tempo.
Cronograma
[editar | editar código-fonte]Semana | Período | Atividade |
---|---|---|
Semana 1 | 29/05 - 05/05 | Levantar ferramentas, Definir cronograma e criar plano de gcs |
Semana 2 | 06/05 – 12/05 | Criação de maquina virtual usando o Vagrant |
Semana 3 | 13/05 – 19/05 | Criação de maquina virtual usando o Vagrant |
Semana 4 | 20/05 – 26/05 | Implementar Integração Contínua |
Semana 5 | 27/05 – 02/06 | Implementar Integração Contínua |
Semana 6 | 03/06 – 09/06 | Implementar Integração Contínua |
Semana 7 | 10/06 – 16/06 | Ponto de Controle 1 (10/06)
Homologar ambiente |
Semana 8 | 17/06 - 23/06 | Ponto de Controle 2 (17/06)
Corrigir problemas encontrados/Implementar melhorias |
Semana 9 | 24/06 - 30/06 | Semana de Contingência |
Semana 10 | 01/07 | Entrega Final |
Andamento do Projeto
[editar | editar código-fonte]Cronograma Atualizado
[editar | editar código-fonte]Semana | Período | Atividade |
---|---|---|
Semana 1 | 29/05 - 05/05 | Levantar ferramentas, Definir cronograma e criar plano de gcs |
Semana 2 | 06/05 – 12/05 | Criação de maquina virtual usando o Vagrant |
Semana 3 | 13/05 – 19/05 | Implementar Integração Contínua |
Semana 4 | 20/05 – 26/05 | Implementar Integração Contínua |
Semana 5 | 27/05 – 02/06 | Implementar Integração Contínua |
Semana 6 | 03/06 – 09/06 | Implementar Integração Contínua |
Semana 7 | 10/06 – 16/06 | Ponto de Controle 1 (10/06)
Homologar ambiente |
Semana 8 | 17/06 - 23/06 | Ponto de Controle 2 (17/06)
Implementar Cheff |
Semana 9 | 24/06 - 30/06 | Implementar Chef |
Semana 10 | 01/07 | Entrega Final |
Ferramentas , Ambiente e Infra-Estrutura
[editar | editar código-fonte]Ferramenta | Tipo | Descrição | Versão |
---|---|---|---|
Jenkins | Integração Contínua | Ferramenta responsável pela integração de testes funcionais automatizados com o repositório ao qual o código está hospedado. | 1.585 |
Git | Controle de versão | Sistema responsável pelo controle de versão do código. | 1.9.1 |
Chef | Ambiente de desenvolvimento | Ferramenta responsável por padronizar o ambiente de desenvolvimeno | 12.4.0 |
Ant | Build | Ferramenta responsável por gerar o build da aplicação | 1.9.3 |
Junit | Teste | Ferramenta responsável por efetuar a automação de testes | 3 |
Instalação e Configuração do Chef-Solo
[editar | editar código-fonte]1 - Execute o comando abaixo para instalar o Chef-Solo
curl -L https://www.opscode.com/chef/install.sh | bash
2- Verifique se o Chef-Solo foi Instalado
chef-solo -v
3 - Estruturando o diretório do Chef-Solo
wget http://github.com/opscode/chef-repo/tarball/master
tar -zxf master
mv chef-chef-repo* chef-repo
rm master
4 - Configurando o knife para ajudar a gerenciar os "Cookbooks"
mkdir .chef
echo "cookbook_path [ '/root/chef-repo/cookbooks' ]" > .chef/knife.rb
5 - Entre na pasta Cookbooks
6 - Instalando o Cookbook "apt". Ele executa um "apt-get update" antes de instalar qualquer pacote
knife cookbook site download apt
tar zxf apt*
rm apt*.tar.gz
7 - Instalando o Cookbook do Android SDK
knife cookbook site download android-sdk
tar zxf android-sdk*
rm android-sdk*.tar.gz
8 - O android-sdk possui dependências dos seguintes cookbooks
-ark -java
Para instala-los, repita o procedimento do passo 7, substituindo o "android-sdk" por "ark" e depois por "java"
9 - A atual versão do cookbook ark encontra-se com problemas na instalação em sistemas linux devido as suas dependências. Trantando-se de um cookbook que pode ser utilizado tanto no windows quanto em sistemas linux, ele deveria verificar e requerer as dependências de acordo com o sistema. Todavia ao instalar no ubuntu, ele pede para instalar o cookbook do 7-zip, disponível apenas para windows. No intuito de sanar esse problema, é necessário entrar na pasta do cookbook "ark", abrir o arquivo "metadata.rb", utilizando o nano, vim, etc. Após aberto, é necessário apagar as dependências do "7-zip" e "windows"
10 - Entre no diretorio "chef-repo" e crie o arquivo solo.rb
11 - Abra o arquivo utlizando o nano, vim, etc. Após aberto insira as instruções abaixo
file_cache_path "/root/chef-solo"
cookbook_path "/root/chef-repo/cookbooks"
12 - Ainda no diretorio "chef-repo" crie o arquivo web.json, utilizando o nano, vim, etc. Insira as instruções abaixo.
{
"run_list": ["recipe[apt]", "recipe[android-sdk]"]
}
13 - Execute o chef-solo
chef-solo -c solo.rb -j web.json
13 - alguns warnings apareceream. Eles são oriundos da atual estrutura do diretório do chef-solo e não interferem na instalação
Instalação Apache Ant
[editar | editar código-fonte]Apache ant é uma ferramenta utilizada para efetuação de deploy e geração de builds em aplicações java. A facilidade de uso dessa ferramenta foi ponto decisivo na escolha para geração de build desse projeto. A seguir o comando para instalação no Ubuntu:
apt-get install ant
Instalação do Jenkins
[editar | editar código-fonte]A instalação do jenkins em um servidor é relativamente simples para sistemas linux , neste projeto em específico utilizou-se uma vm hospedada na Digital Occean com o sistema operacional Ubuntu. Dessa maneira , a seguir será mostrado o passo a passo de como instalar o jenkins em máquinas com o ubuntu. A referência utilizada para essa instalação também possui o passo a passo em outras distribuições linux .
Instalação
[editar | editar código-fonte]No terminal execute os seguintes comandos:
wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add - sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list' sudo apt-get update sudo apt-get install jenkins
Atualização
[editar | editar código-fonte]Caso queira atualizar o jenkins basta executar os seguintes comandos no terminal:
sudo apt-get update
sudo apt-get install jenkins
Configuração do Projeto no Jenkins
[editar | editar código-fonte]Instalação de Plugins
[editar | editar código-fonte]Para realização da integração contínua nesse projeto se fez necessário o uso de alguns plugins para jenkins:
- EMMA plugin
- Ant plugin
- Android Emulator plugin
- GIT plugin
- GitHub plugin
A seguir um breve passo a passo de como instalar os plugins necessários.
- Na tela inicial clique em Gerenciar Jenkins
- Em seguida clique em Gerenciar plugins
- Na aba Disponíveis pesquise e marque o plugin desejado.
- Em seguida clique em Baixar agora , instalar e depois reiniciar. O jenkins pode levar algum tempo para reiniciar.
Configuração da chave SSH
[editar | editar código-fonte]Para que o jenkins consiga se "comunicar" com o projeto no github é necessário que seja configurada uma chave ssh da VM onde o jenkins está hospedado em algum usuário no projeto. Em alguns projetos , costuma-se criar um usuário só para o jenkins , por conta disso. A seguir um passo a passo de como fazer essa operação.
Na estação onde o jenkins encontra-se instalado execute o seguinte comando:
sudo -u jenkins ssh-keygen
Isso irá criar uma chave ssh no seguite diretório:
/var/lib/jenkins/.ssh/id_rsa.pub
Em seguida copie o conteúdo desse arquivo e crie uma SSH KEY no perfil do seu usuário no github passando esse conteúdo.
Configuração do Projeto
[editar | editar código-fonte]O projeto AKAN foi desenvolvido utilizando o eclipse como ferramenta para desenvolvimento. Devido a isso , para criação de testes para aplicação se faz necessário a criação de um outro projeto só para Testes. Dessa maneira isso reflete a configuração do jenkins que, como será explicado a seguir , requer a criação de dois jobs um para cada projeto.Outro ponto a se destacar é que com a configuração que será mostrada o jenkins "escuta" todas as branchs do repositório e assim que algum push é efeito , ele efetua o merge , se não der conflito e se build for gerado sem problemas , o próprio jenkins executa o push em uma branch devel. Dessa maneira temos uma branch referência de desenvolvimento sempre atualizada.
Primeiro iremos configurar o projeto principal:
- Na tela inicial do jenkins clique em Novo Job
- Coloque o nome do projeto e em seguida cliquem em Construir um projeto de software free-style.Uma tela com configurações mais avançadas será aberta.
- Na seção Gerenciamento de Código fonte marque a opção Git .Em repository url coloque a url do repositório no formato SSH.
- Em branchs to build coloque o nome da branch ao qual deseja que o jenkins "observe" quando alguma mudanças é efeutada.No akan o jenkins escuta todas as branchs assim fora colocado '**'.
- Na seção navegar no repositório deixa na opção Auto.
- Em Additional Behaviours clique em adicionar e selecione Merge before build.
- Deixe em branco ou coloque origin no campo name of repository , em branch to merge coloque o nome da branch ao qual deseja que seja efeutado o merge .As outras opções pode deixar o que veio por padrão.
- Na seção Trigger de Builds marque a opção Build when a change is pushed to GitHub.
- Na seção ambiente de build não marque nada.
- Na seção Build adicione um novo passo selecionando a opção execute shell .Aqui serão executados alguns comandos necessário para execução do build no caso do Akan é executado o comando responsável por atualizar as dependências do projeto em android .
- Ainda na seção build marque a opção Invocar Ant e coloque o seguinte comando : clean debug
- Em ações após build Selecione Git Publisher.
- Marque a opção Push Only If Build Succeeds. E adicione a branch ao qual deseja efetuar o push.
Configuração do projeto de teste.
- Na tela inicial do jenkins clique em Novo Job
- Coloque o nome do projeto e em seguida cliquem em Construir um projeto de software free-style.Uma tela com configurações mais avançadas será aberta.
- Na seção Gerenciamento de Código fonte marque a opção Git .Em repository url coloque a url do repositório no formato SSH.
- Em branchs to build coloque o nome da branch ao qual deseja que o jenkins "observe" quando alguma mudanças é efeutada.No projeto de test do akan o jenkins escuta a branch working_gcs.
- Em Additional Behaviours não selecione nada.
- Na seção Trigger de Builds marque a opção Construir após a construção de outros projetos
- Em Projetos observados coloque o nome do projeto ao qual deseja que dependa do build. Neste caso fora colocado o projeto Akan
- Marque a opção Disparar apenas se o build estiver estável
- Na seção Ambiente de build marque a opção Run android emulator during build . Em seguida coloque as propriedadeos do emulador como desejado. Observação: Caso tenha problema por conta do Target/ABI . Ver seção possiveis problemas e soluções.
- Na seção Build adicione um novo passo selecionando a opção execute shell .Aqui serão executados alguns comandos necessário para execução do build no caso do Akan é executado o comando responsável por atualizar as dependências do projeto de teste em android .
- Ainda na seção build marque a opção Invocar Ant e coloque o seguinte comando : clean emma debug install test
- Em ações após build Selecione Publish html reports
- Passe o endereço onde o emma grava os resultados em fomato html. No projeto Akan esse endereço é : /var/lib/jenkins/jobs/AkanTest/workspace/bin/
- No campo index page coloque o nome do arquivo : coverage.html
- Ainda na seção Ações de pós-build . Adicione um passo e selecione a opção Record Emma coverage report.
Possiveis problemas e soluções
[editar | editar código-fonte]Target/abi não encontrado
[editar | editar código-fonte]Caso não saiba qual target/abi exato utilizado pela versão do android especificado pelo jenkins , na estação do jenkins vá para o diretório /var/lib/jenkins/tools/android-sdk/tools e execute o seguinte comando:
./android list target
Esse comando listará todos os targets de forma detalhada instalados na estação do jenkins. Com isso copie um dos itens que estiver descrito no campo Tag/ABIs da versão do android especifcada nas configurações do projeto no jenkins e coloque em Target ABI na seção de propriedades do emulador.
Problemas com o operador diamonds do java
[editar | editar código-fonte]Durante a configuração geração de build deste projeto teve se o seguinte erro relacionado com a versão do java configurada no arquivo do ant:
diamond operator is not supported in -source 1.6 (use -source 7 or higher to enable diamond operator)
Nesse caso o operador diamond (<>) não é reconhecido em versões do java menores que o 7 . No ant a versão do java configurada é a 6 (1.6) uma possível solução é alterar o arquivo build.xml localizado no diretório /var/lib/jenkins/tools/android-sdk/tools/ant/ muando o valor das variáveis java.source e java.target para 1.7 entre as linhas (70~80).
Enconding UTF-8
[editar | editar código-fonte]Outro problema enfrentado foi com relação ao não reconhecimento do "UTF-8" por parte do ant. O seguinte mensagem de erro é apresentada:
unmappable character for encoding UTF8
A solução encontrada foi novamente fazer algumas alterações no arquivo build.xml localizado no diretório /var/lib/jenkins/tools/android-sdk/tools/ant/ mudando o valor da variável java.encoding(linhas 70~80) para "CP1252".
Durante a execução dos testes o emulador não conecta
[editar | editar código-fonte]Esse problema é caracterizado pela seguinte mensagem de erro apresentada no console durante a geração de build no projeto de testes:
error: device offline
A solução encontrada foi instalar o pacote sdk Google Api (neste projeto Google API 18) na estação do jenkins. Assim vá para o diretório /var/lib/jenkins/tools/android-sdk/tools/ e execute o seguinte comando:
./android list sdk --all
Isso listará todos os pacotes sdk disponiveis. Em seguida procure pelo pacote com o seguinte nome: Google APIs, Android API 18. Instale-o executando o seguinte comando:
android update sdk -u -a -t numero_do_pacote.
Observação. O pacote utilizado fora o Google APIs, Android API-18 , não se sabe por exemplo se com o pacote Google APIs, Android API-19 o problema se perpetuará.
Referências
[editar | editar código-fonte]Instalação jenkins:
https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins
Configuração:
https://wiki.jenkins-ci.org/display/JENKINS/Building+an+Android+app+and+test+project
http://blackriver.to/2012/02/android-continuous-integration-with-ant-and-jenkins-part-1
http://blackriver.to/2012/02/android-continuous-integration-with-ant-and-jenkins-part-2
http://adventuresinqa.com/2012/08/02/robotium-jenkins-and-ant/
http://www.tristanwaddington.com/2011/06/automated-android-builds-with-jenkins/
Instalando imagens alvo pela linha de comando:
http://developer.android.com/tools/devices/managing-avds-cmdline.html