Projetos PHP e Integração Contínua

Estamos lutando aqui na 3Jane para alcançarmos um formato indolor de Continuous Integration ( aqui e aqui ) em nossos projetos – que são (até então) em PHP.

Existe um número relevante de ferramentas disponíveis, o problema esta sendo fazer com que elas sigam um fluxo natural no projeto. Ou as ferramentas precisam de uma adaptação para PHP (como o CruiseControl com o PHPUnderControl), ou as ferramentas não se encaixam, ou são muito limitadas.

Embora um pouco complexo, estamos achando algumas coisas boas. Para começar, tinhamos decidido apostar no CakePHP, um framework sólido e com grande similaridade com o Rails. Ficamos realmente satisfeitos com a organização da “criança” e de como ele é bem feito. E também tem o fato de que o CakePHP já vem com uma integração com o SimpleTest, que até onde pude ver, a ponte entre eles é sólida e sem “adaptações” incomodas – até porque o SimpleTest também é em PHP.

Acontece que pelo CakePHP ser bem completo, ele também é mais lento que outros frameworks e por motivos de força maior decidimos trocar para o Code Igniter, que também é um bom framework, mas não possui tantas camadas quanto o CakePHP e teremos que “digitar mais”. Outro ponto fraco do Code Igniter com relação ao CakePHP é o bake, que é um script generator do CakePHP que agiliza muito a vida.

Quanto aos testes no Code Igniter ele já vem com uma library bem simples para teste unitário, mas é tão simples que estou propondo aqui que troquemos para o SimpleTest ou PHPUnit. Como este último parece ter uma integração com o PHPUndercontrol, estou lendo como plugá-lo ao CodeIgniter.

Já construímos o Tracer Bullet para os testes do ambiente e estamos implantando-o. Estou vendo o Phing para automatizar o processo de deploy, mas ainda não parei para estuda-lo de verdade. Essa é uma das minhas metas nos próximos dias.

Para controle de código, migramos do SourceSafe para o SubVersion e apesar de alguns problemas com o Tortoise, valeu a pena. Pra ser bem sincero, o engraçado é como sempre os problemas envolvem o Windows. Para controle de bug/issues estamos usando o Jira e como Wiki o Confluence. Ah, e para a documentação do nosso código estamos usando o phpDocumentator.

Ufa! Acho que é isso… O problema é conseguir tempo pra ver tudo isso e dar continuidade no projeto. Mas posso dizer que demos um “salto quântico” no processo de desenvolvimento aqui na 3Jane. Se você quiser uma lista organizada e decente das ferramentas que podem te ajudar no desenvolvimento em projetos PHP, o Dave Marshall publicou um top 10 no blog dele.

Por fim, deixo com vocês um slide falando sobre PHP + Continuous Integration :

Usando o Authenticate do CakePHP


Estou trabalhando ultimamente com o CakePHP (1.2) e achei um componente muito útil: o AuthComponent. Ele centraliza todo o fluxo de autenticação no sistema e se você seguir algumas regras básicas dele, poderá fazer toda parte de login do seu site com praticamente esforço zero.

Primeiro passo é definir se a maior parte do seu site será publica ou privada por que isso dirá onde você deve acionar o Auth. Se você notar que quase todas as áreas do seu site será de acesso publico, é melhor chamar o Auth direto nos controllers que terá actions privadas. Caso não, você pode colocar direto no app_controller da sua aplicação.

Não que você não possa colocar direto na configuração de chamada do auth a lista de controllers e/ou actions e suas respectivas visibilidades, mas é só por uma questão de economia de esforço

A idéia é simples, e vou assumir que o controller com o auth será o app_controller


class AppController extends Controller {

var $components = array('Auth');

function beforeFilter() {

// Auth config
$this->Auth->allow(array('action_publica'));
$this->Auth->loginError = __("Usuario nao encontrado", true);
$this->Auth->loginAction = array('controller' => 'users', 'action' => 'login');
$this->Auth->loginRedirect = array('controller' => 'users', 'action' => 'profile');
}

}

No exemplo acima, coloquei a chamada do componente no var $components = array(‘Auth’);, logo depois no beforeFilter ( que sempre é executado antes do controller) configurei o Auth da seguinte forma: o allow() serve para você dizer quais actions são de acesso publico, o loginError() é a mensagem de erro, o loginAction() define onde esta o action de login e o loginRedirect() serve pra apontar pra onde o usuário será redirecionado após o login. Agora basta no meu controller login colocar as actions login() e logout() que ficaria parecido com o seguinte:


class UsersController extends AppController {

function login() { }

function logout() {
$this->redirect($this->Auth->logout());
}

}

Assim ficar o login e o logout. Simples não ? O action login() pode ficar completamente em branco e o logout() faz um redirect pro logout do Auth. E a view do login também é bem simples:


<div class="users">

<?php if ($session->check('Message.auth')):?>
<?php $session->flash('auth'); ?>
<?php endif;?>

<?php echo $form->create('User', array('action' => 'login'));?>
<fieldset>
<legend><? __('Login') ?></legend>
<?= $form->input('username'); ?>
<?= $form->input('password'); ?>
</fieldset>
<?php echo $form->end('Logar');?>
</div>

Na view eu coloquei o $session->flash(‘auth’); principalmente para mostrar a mensagens do tipo “usuário não encontrado”, que você configura previamente no Auth.

Algumas considerações finais

O Auth tem várias configurações que podem ser alteradas, mas por default ele assume que você tem um modelo chamado User, que tem dois campos: username e password. Ele também assume que o campo password foi criptografado com um hash dele. A questão da criptografia do password é a única coisa que não pode ser alterada – ele sempre assume que o password esta criptografado.

Para saber mais sobre o Auth, vá na página da API dele e da documentação no CookBook. Agora vou continuar estudando sobre o ACL para definir as permissões de usuário automaticamente pelo grupo que ele pertence. Quando estiver com melhores conhecimentos tento escrever algo sobre isso.