Voltando a postar no blog depois de MUITO tempo… praticamente um post de páscoa. Mas vamos voltar com a corda toda! Eu prometi há muito tempo um post sobre Integração Contínua – e cá está ele .

Antes de mais nada, vamos à definição de CI (Continuous Integration):

Em engenharia de software, Integração Contínua (IC) implementa  continuamente  processos de aplicação de controle de qualidade – pequenos pedaços de esforço, aplicados frequentemente. Integração Contínua visa melhorar a qualidade de software e reduzir o tempo gasto para entregá-lo, substituindo a prática tradicional de aplicar o controle de qualidade depois de completo todo o desenvolvimento.[1]

Indo além: a prática da Integração Contínua vai melhorar a Qualidade e a Velocidade de entrega de seus softwares, e de cada nova versão que ele venha a ter. IC também é uma das práticas que auxiliam metodologias ágeis.

A premissa é de que tenhamos uma parte de nosso processo que aconteça continuamente – parte essa que deve construir uma versão/build/release/pacote/<insira aqui o que você chama de versão nova de seu software> … lógico que para ter uma versão nova, não basta um desenvolvedor dizer que está pronto; a nova versão está condicionada ao sucesso de testes previamente estabelecidos, que vão acontecer a cada nova TENTATIVA de realizar uma nova versão. Tentativa com sucesso: novo release; falha: esqueça esse build.

Lógico que nós, desenvolvedores evoluídos, não gostamos de reinventar a roda e tentamos sempre tirar proveito de soluções bem estabelecidas de software para resolver nossos problemas (e é para isso que o software serve: para resolver problemas). Existem muitas ferramentas prontas para nos ajudar na tarefa da integração contínua, automatizando o processo de recuperação de uma nova versão candidata, execução de testes e finalização/empacotamento/deploy.
Entre elas temos o CruiseControl (com versões .NET e Ruby e sua adaptação para o PHP: phpUnderControl), Continuum, Gump, Go, Tinderbox … mas de todos acredito que o mais simples (e direto ao ponto) e extensível seja o Jenkins (ex-Hudson).

Atente-se para o fato que até então não citei nada exclusivo ao PHP, porque não é específico. IC é relativo a software, em qualquer linguagem. Mas por que diabos o artigo é Integração Contínua E PHP?

Que tal um exemplo de como pode ser um processo de Integração Contínua com PHP?

Imagine o cenário: Estamos desenvolvendo um software em PHP, usando o PHPUnit e versionando-o com Git.

Nosso time já desenvolveu bastante, “comittou” algumas revisões, realizamos um merge e achamos que podemos mandar nossa versão para testes. Podemos nesse ponto mandar essa revisão para a Integração Contínua. Se tudo estiver ok, teremos um software que PODE ir para homologação, onde o cliente/gerente/Product Owner vai avaliar se atendemos suas expectativas – se passarmos desse ponto temos um software que PODE ir para produção.

Porque a enfase no PODE? Não necessariamente esse software vai para produção, ou homologação, mas está pronto e, em tese, sem problemas técnicos para tal.

O Nosso servidor de Integração Contínua está configurado para observar um repositório git acessível a ele. Quando há uma nova revisão ele tentará criar um build.

Temos uma ferramenta excelente para realizar builds para PHP: Phing. Este cara é baseado no Apache Ant e basicamente ele funciona realizando tarefas previamente configuradas que culminarão em um novo release. Podemos alterar arquivos (mudando as configurações de ambiente por exemplo), realizar queries, movimentação de arquivos e, para nossa finalidade aqui, rodar os testes do PHPUnit – além de um sem-número de funcionalidades.
Configuramos o Phing para alterar um arquivo de configuração, rodar nossa suíte de testes e construir um Phar ao final do processo.

Nosso servidor de Integração Contínua, que executou o Phing para nós, identificou que 2 testes não passaram com a nova configuração. Nosso time fez o ajuste necessário, levantamos a nova revisão, o Jenkins (opa, já estou dizendo que usamos ele!) rodou a nova tentativa de build e … Funcionou! Agora temos um Phar, que o Jenkins/Phing pode se encarregar de entregar no servidor de Homologação se quisermos.

Facilita a vida? É lógico!

Mas lembrem este é só um exemplo, talvez nem o melhor – mas já dá para ter uma idéia do poder que a Integração Contínua pode dar para seu projeto.

Em breve (prometo @nshgeek e @thiagophx, muito em breve) falamos aqui sobre como fazer o Jenkins funcionar (e bem) com desenvolvimento PHP.

Abraço.