Integração Contínua

De Wiki Expresso V3
Ir para: navegação, pesquisa

Conteúdo

Introducao

O processo de teste de software visa fornecer informações sobre sua qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.

A qualidade de uma aplicação pode variar significativamente de sistema para sistema. Os atributos qualitativos previstos na norma ISO 9126 são: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.

De forma geral, mensurar o bom funcionamento de um software envolve compará-lo com elementos como especificações, outros softwares da mesma linha, versões anteriores do mesmo produto, inferências pessoais, expectativas do cliente, normas relevantes, leis aplicáveis, entre outros. Enquanto a especificação do software diz respeito ao processo de verificação do software, a expectativa do cliente diz respeito ao processo de validação do software.


A Comunidade

A iniciação a um processo de testes, mesmo que ainda distante de um processo sedimentado na engenharia de software considerando um processo de integração contínua junto ao desenvolvimento, deu-se com a disponibilização de um processo de testes inicialmente baseado na utilização da ferramenta testlink.

A partir da integração do expresso com a comunidade alemã tine20, fora sedimentando-se um processo de desenvolvimento cooperado voltado para testes, considerando os frameworks e ferramentas livres para tal.

A comunidade Tine20, esquematicamente utiliza-se do seguinte esquema para Integração Contínua:

Tine.png

Processo Ágil e Integração Contínua

Ceo-pack-scrum-powerpoint.jpg
A integração Contínua, caracteriza-se por, obviamente, continuamente integrar mudanças que ocorrem no desenvolvimento e manutenção de um sistema. O Processo de Integração Contínua está integrado ao Processo de Desenvolvimento Ágil baseado nos metodos do Scrum que pode ser melhor entendido consultando-se seu Manual Scrum.


Integração Contínua tornou-se muito importante na comunidade de desenvolvimento de software e isso provavelmente ocorreu devido ao grande impacto causado pelas metodologias ágeis. Em equipes que adotaram tais metodologias (eXtreme Programming, Scrum, entre outras), integração contínua é um dos pilares da agilidade, garantindo que todo o sistema funcione a cada build de forma coesa, mesmo que sua equipe seja grande e diversas partes do código estejam sendo alteradas ao mesmo tempo.

Para o Expresso trataremos os testes com base na técnica denominada caixa-cinza, que tanto reúne aspectos internos como externos da aplicação.

Framework de Testes

O Framework de testes constitui-se de um conjunto de processos, papéis, workflows e ferramentas que objetivam agregar qualidade às entregas do produto de software balizadas por uma metodologia ágil de desenvolvimento orientado a testes.

Os processos, papéis e gestão da Integração contínua, resumidamente podem ser observados, conforme figura abaixo. IC.jpg


Gestão do Projeto - Redmine

Redmine fluid icon.png
A ferramenta Redmine fora adotada como ferramenta de gestão de projeto para o ExpressoV3. A facilidade de gerenciamento aliada a sua simplicidade e seu grande potencial de compatibilidade com outras ferramentas por intermédio de plugins foram fundamentais para esta adoção. Como exemplo de alguns plugins utilizados:
Redmine Backlog
Redmine TestLink Plugin
Redmine Hudson Plugin

Gestão de Integração Contínua - Jenkins

Pelas mesmas razões anteriores, o software Jenkins fora escolhido para fazer a gerência da Integração Continua do Projeto. A visibilidade da integração contínua na comunidade tine20 pode ser consultada em Tine20-Integração Contínua.

Dentre suas características podemos destacar:

Gerenciamento da execução de testes
Feedback imediato para o desenvolvedor
Integração com Selenium para simulações de navegação
Construção de builds dinamicamente
Gerência de revisão e aprovação de implementações
Interface para testes unitários
Validações de estrutura de código

Inicialmente, para o processo do Expresso foram criados os seguintes JOBS(Unidades de execuções do Jenkins):

NO COMMIT   - Sempre que houver um commit(alteração de código) no repositório, será disparado um job de testes,
              proporcionando um feedback imediatamente após a execução do teste para o desenvolvedor.
DIARIAMENTE - Durante o dia vários desenvolvedores podem estar modificando código no repositório. Para testar
              a integração destes diversos códigos em um determinado ponto, optou-se por executar um teste 
              as 23:00h, que também irá dar feedback nos testes em que existirem falhas.
POR VERSÃO  - Sempre que o fechamento de uma versão for cumprida, será liberado um teste visando realizar a 
              integração no ponto de liberação de versão.
SERVIÇOS    - Este job será iniciado visando suprir informações relativas as serviços que são executados e a
              quantidade de acessos a estes serviços.
              Por exemplo, deseja-se saber se uma versão contribuiu com mais ou menos acessos ao banco de dados
EVENTUAIS   - Para testes específicos relativos a alguma nova implementação ou validação.

Gerenciamento de Revisões - Gerrit

Diffy-w200.png
Para gerenciamento de revisões é utilizada ferramenta Gerrit.

Gerrit é um sistema de revisão de código baseado na web, o que facilita as revisões de código on-line para projetos que usam o sistema de controle de versão Git. A interface de usuário de Gerrit é baseado no Google Web Toolkit e sua implementação Git é baseado em JGit.

O Gerrit permite fazer revisões de código mais fácilmente, mostrando as alterações em uma exibição lado-a-lado. Ele também permite ao revisor adicionar comentários para cada linha alterada, visando aprimorar a qualidade do código.

Um membro da comunidade pode usar Gerrit e sugerir uma alteração de código. Outros desenvolvedores podem rever a alteração de código e sugerir melhorias. Uma vez que as alterações sugeridas sejam aceitas pelos revisores, eles podem ser aplicados via Gerrit para o repositório Git subjacente, no caso o Gitorious, conforme mostra a figura acima.

Repositório único de código - Gitorious

Gitorious2013.png
Projetos de software envolvem muitos arquivos/programas que necessitam ser orquestrados para geração de um produto. Organizar estes arquivos/programas torna-se um grande esforço, especialmente quando existem muitas pessoas em diferentes grupos envolvidas.

O produto resultante do Processo de Integração, revisões e testes será armazenado/mergeado em um repositório central. No caso do expressoV3 este repositório é residente em gitorious.

Automação de geração de Build

Phing.gif

A geração de builds(releases) para teste, por vezes pode ser uma tarefa bastante complicada, principalmente quando envolve sistemas maiores, dependentes de esquemas de bancos de dados, execução de privilégios, e customização de arquivos. Manualmente esta atividade estaria sujeita a introdução de erros. Portanto é fundamental que se tenha um processo automatizado de geração de builds. Para estas gerações é utilizado o phing(PHing Is Not GNU make).

Testes tipo caixa Branca

Jenkins.jpg

São testes voltados para o software, tentam expor o código de maneira a garantir a qualidade do software. Para o Expresso usa-se os testes unitários já desenvolvidos na comunidade como fonte principal.

Estes testes também são incorporados à gestão do Jenkins.





São testes de diagnósticos de codificação, como por exemplo:

PHP Mess Detector(PHPMD):
   Suboptimal code
   Overcomplicated expressions
   Unused parameters, methods, properties
PHP_Depend:
   Analisa métricas do código php
PHP_cpd:
   Copy Paste Detector para código php
PHP_unit:
   Testes unitários voltado aos casos de teste do expresso(TDD)
Testes Funcionais:
   Integração com Selenium

Feedback Imediato

Principalmente em projetos com características de desenvolvimento comunitário como é o caso do Expresso, torna-se necessário que o desenvolvedor tenha retorno imediato sobre sua implementação comitada no repositório em relação ao conjunto de funcionalidades existentes no sistema. Não pode ser quebrada, e sendo, o desenvolvedor deve ter meios automatizados de receber o feedback de algum problema detectado.
Para que se tenha a produtividade almejada em relação ao desenvolvimento e os testes, o framework de testes deve disponibilizar mecanismos de comunicação para notificação aos envolvidos do “status” de sua atividade.

Ferramentas pessoais
Espaços nominais

Variantes
Ações
Navegação
Ferramentas