No artigo "Como rodar testes unitários com o Adianti Framework" (www.adianti.com.br/forum/pt/view_4273?como-rodar-testes-unitarios-co), vimos como escrever testes sobre pequenas unidades de nosso software (métodos) que podem ser automatizados, ou seja, rodar com uma certa frequência, como todo dia, ou toda hora. Neste artigo, vamos falar em como implantar um processo de integração contínua em uma aplicação com o Adianti Framework.

Integração contínua é uma prática de trabalho no desenvolvimento de software, que visa integrar o software frequentemente, de preferência várias vezes por dia, sendo que o ideal é rodar a integração contínua a cada commit. Dentro de um processo de integração contínua, podemos rodar tarefas como compilação (verificação de sintaxe), verificação de testes unitários, verificação de migrations de banco, inspeção e análise de boas práticas de código-fonte (best practices), dentre outros.

O PHP oferece um conjunto de ferramentas muito práticas para integração contínua, dentre elas podemos citar:
- PHPCS: Verifica a aderência do código à certos padrões (Ex: PSR);
- PHPMD: Verifica boas práticas de escrita de código (Ex: Tamanho de variáveis)
- PHPCPD: Detector de copy e paste, detecta trechos com repetições de código
- PHPLOC: Realiza medições sobre o código-fonte (quantidade de classes, métodos, linhas, complexidade)
- PHPUnit: Realiza testes unitários automatizados.

Neste artigo, vamos preparar receitas (scripts) para rodar integração contínua em uma aplicação do Framework em dois ambientes:
- Gitlab-CI (www.gitlab.com) : Ambiente de integração contínua do Gitlab, um software open source;
- Travis (www.travis-ci.org) : Ambiente de integração contínua como serviço, na nuvem.

Para utilizar integração contínua, você precisa de receitas de builds, que são receitas disparadas automaticamente quando comitamos no repositório. Quando o build roda, um ambiente isolado é criado no servidor de builds (geralmente utilizando containers docker), e os testes são rodados neste ambiente.

O primeiro formato de receita que vamos analizar é do Gitlab-CI. Para usar o Gitlab-CI, precisamos criar uma receita de build chamada .gitlab-ci.yml. No início da receita, identificamos a imagem que será utilizada pelo container para rodar os testes. Veja imagens disponíveis no site do dockerhub. Aqui, utilizamos php:latest para pegar a última versão disponível. A seção before_script contém comandos de preparação, para rodar antes dos testes. Ali, instalamos alguns pacotes (git, zip), instalamos o composer, bem como a biblioteca PHPUnit. Também aumentamos o limite de memória para os testes. Dentro da receita, temos dois jobs (job_lint, e job_phpunit). Estes jobs fazem parte de dois stages, que são as fases do build (check_syntax, e unit_tests). Cada job tem instruções. No caso do lint, rodamos um script para verificação recursiva de sintaxe, que você pode obter aqui (www.pastebin.com/EY2PNS0w). Já o job_phpunit, roda o próprio PHPUnit sobre a pasta App/Tests, que é a pasta dos testes.

.gitlab-ci.yml


Dentro do Gitlab-CI temos uma área de builds, chamada Pipelines. Nesta área, visualizamos os builds disparados a cada commit. Ao clicarmos sobre o job, visualizamos os comandos disparados, desde a criação do container de testes, até o teste em específico.



O travis é um serviço na nuvem que disponibiliza builds automatizados. Para projetos open source ele é gratuito, para projetos privados existe um custo envolvido. Para utilizar o travis, também precisamos criar uma receita de build. A seguir, temos uma receita de build para o Travis. Esta receita realiza verificação de sintaxe recursiva (lint) em toda a pasta App (www.pastebin.com/EY2PNS0w), e também os testes unitários. Este arquivo também segue o formato YML, e em seu início define algumas características sobre o container de testes que será criado, como a linguagem e versão disponíveis. Na seção before_script, colocamos os comandos de preparação, como instalação de pacotes necessários para os testes. Neste caso, instalamos a PHPUnit. Na seção script, colocamos os comandos de build. Neste caso, também estamos realizando verificação de sintaxe e rodando os testes unitários.


.travis.yml


Sempre que um commit for realizado, vemos os builds rodando dentro do ambiente do Travis. Ao clicarmos no build, podemos visualizar o log com os comandos do build rodando, da mesma maneira que no Gitlab.



É isto pessoal.