Salve, galera.

Desta vez, vamos fazer algumas brincadeiras com uma ferramenta que citei há algum tempo: Jenkins! Este é um servidor de Integração Contínua (ou Continuous Integration, para os ingleses de plantão), desenvolvido em Java, mas extremamente robusto e versátil para qualquer linguagem de programação. Vamos falar sobre a Instalação, Plugins, Detalhes em Jobs e Dicas adicionais.

Bom, antes de mais nada, gostaria de agradecer ao Sebastian Bergmann, pois este artigo é baseado em seu trabalho Template for Jenkins Jobs for PHP Projects, o qual deu muita simplicidade ao processo como todo – recomendo a leitura!

Só retomando: Jenkins é um servidor de Integração Contínua – uma ferramenta essencial para processos de desenvolvimento ágil que pode integrar diversas práticas de QA e outras ferramentas – automatizando builds de software… falei um pouco sobre isso em um artigo no passado.

Lembram da VM que criamos no último artigo? Vamos usá-la para exemplificar o processo em um ambiente “remoto”. Vou supor que o hostname que criamos era dev, portanto podemos acessar nossa VM por http://dev.local.

Instalação do Jenkins

Vamos instalar o Jenkins diferentemente da maneira como sugeriu o Sebastian – uma maneira mais “ubuntu-way-of-life”. Na wiki do Jenkins, encontrei este guia, que deixará o sistema melhor administrável para este nosso Ubuntu (o pacote por si só já cria usuário de sistema, scripts de (re)inicialização e parada e já coloca no start-up do SO, além de a atualização também poder vir via apt). Peço somente que não faça (ainda) a parte “Setting up an Apache Proxy for port 80 -> 8080″. Depois de tudo setado, se quiser, pode fazer à vontade.

Se tudo deu certo você tem agora o Jenkins rodando e você pode aceesá-lo em http://dev.local:8080.

Plugins do Jenkins

Neste ponto, você pode seguir o guia do Sebastian a partir de “Required Jenkins Plugins”, ou seja, você deve instalar alguns plugins do Jenkins para que, quando nosso código chegar lá, já esteja tudo pronto – os plugins são: Checkstyle, Cloverphp, DRY, HtmlPublisher, jDepend, Plot, PMD, Violations e xUnit. Acrescente à lista o Phing – sim, vamos mudar um pouco a receita do tio Sebastian (odeio simplesmente copiar o trabalho alheio).

Ferramentas PHP

Antes de instalar, vamos revisar o que vamos verificar em nossos projetos:

• Testes Unitários – PHPUnit
• Estilo de código – PHP_CodeSniffer
• Código Duplicado (o famoso Ctrl+C, Ctrl+V – que pode criar pontos de evolução distintos para a mesma funcionalidade) – PHPCPD
• Bagunça no código (buscamos aqui pontos de refatoração) – PHPMD
• Medição e análise estrutural – PHPLoc
• Diversas Métricas de Software, adicionais ao item anterior – PHP_Depend

Na instalação que fizemos de PHP, contemplamos a PEAR/PECL (por isso instalamos o xdebug via pecl). Caso você não tenha instalado, faça isso – não dá pra continuar sem. Bom, tio Sebastian também deixou as coisas bem adiantadas e na seção “Required PHP Tools” do link de seu Template ele tem uma maneira muito boa de instalar todos de uma vez:

# pear upgrade PEAR;
# pear config-set auto_discover 1;
# pear install pear.phpqatools.org/phpqatools pear.netpirates.net/phpDox

Neste ponto, você deve ter todas as ferramentas citadas logo acima. Mãããããss queremos o Phing para ser nosso construtor de Projetos… Para tal, execute o seguinte:

# pear channel-discover pear.phing.info
# pear install -a phing/phing

Pronto. Phing também instalado. Não vou entrar em detalhes por enquanto sobre ele. Por hora, basta saber que ele executará tarefas de maneira automatizada.

Configurando o Projeto

O Phing, assim como seu primo javeiro Ant, funciona a partir de um arquivo de descrição de build. Tio Sebastian preparou um para Ant, e aqui está um para Phing. Crie um arquivo build.xml na raiz de seu projeto com o conteúdo deste gist.

Vale atentar para as linhas de 6 a 8 – nelas, configuramos os diretórios principais para nosso build.
Também para o target na linha 72, onde configuramos o codesniffer para o padrão de código do Symfony2 … mas este não está na lista default de padrões do phpcs, que tem entre outros os padrões PEAR E Zend). O que não nos impede de adicionar padrões – e instalei o padrão do Symfony2 usando este projeto.

Por último, mas não menos importante, estou supondo que sua suíte de testes se utilize de um bootstrap(.php) E um (phpunit.)xml de configuração. Adicionalmente ao template do Sebastian, eu coloquei uma verificação: se o xdebug estiver instalado (no caso de nossa VM está), vamos executar o teste completo com relatórios de cobertura, senão somente a execução dos testes unitários.

Usando o Template de Job (adaptação)

1. Realize o checkout do template no diretório de jobs do Jenkins

   # cd /var/lib/jenkins/jobs
   # git clone git://github.com/sebastianbergmann/php-jenkins-template.git php-template
   # chown -R jenkins:nogroup php-template/

2. Reinicie o Jenkins

   # /etc/init.d/jenkins restart

3. Vá para a interface web do Jenkins (se você ainda não mudou nada, deve estar em http://<hostname>.local:8080) e clique em “New Job”
4. Insira um nome de Job (Job Name)
5. Selecione “Copy Existing Job” e insira no input que aparece “php-template”
6. Clique em OK
7. Entre no projeto (se já não estiver nele) e acesse a opção “configure”
8. Desabilite a opção “Disable Job”
9. Configure o Job para seu controle de versão (Source Code Management) (há plugins dos mais variados, inclusive um plugin que utiliza um filesystem sem controle de versão –  para o GIT, eu precisei instalar adicionalmente os plugins Jenkins Git e Git Parameter)
10. Configure o Build Trigger – por hora, use o Poll SCM (agendamento do “fetch” do SCM)
11. Em Build, exclua o item “ant” e em “Add Build Step” selecione “Invoke Phing Targets”, e depois selecione a Versão default do Phing
12. Clique em Save

Para não dizer que sou egoísta ou algo do gênero, eu peguei um projeto do qual nem participo, mas conheço muito bem o mentor, para testar isso tudo. Conhecem o Respect? Pois bem, ele foi minha cobaia… e como era de se esperar … tudo deu muito certo! Seguem algumas capturas:

Onde podem ocorrer problemas? Permissionamento – verifique se o Jenkins tem acesso ao projeto.

O Jenkins tem também muitos truques na manga. O Jogo de Integração Contínua (onde quem melhora mais o software ganha mais pontos – brincadeira que pode motivar uma equipe a melhorar o próprio trabalho), Ferramentas mil no tocante à distribuição do software, entre tantas outras coisas… você vai perder um tempo só analisando os plugins disponíveis.

Lógico que este artigo não se direciona somente a quem utiliza VMs ou a quem configurou uma pelo artigo anterior. Com poucos ajustes, você pode levantar um Jenkins em qualquer lugar.

O Phing será meu próximo assunto – uma poderosíssima ferramenta sem sombra de dúvida.

Dúvidas? Comentários? A última seção desta página serve para isso!

Até o próximo artigo.