Testando rapidamente projetos PHP, ou com Vagrant, ou com Docker ou com Servidor Web embutido

Olá, pessoal!

Dica rápida para quem quiser testar algum projeto PHP usando o Vagrant, ou o Docker, ou o Servidor Web embutido no PHP.

Vagrant

Já conhece o https://phpagrant.github.io/ ? Nada mais é do que uma lista de sites geradores de Vagrantfile (e tudo o mais que você precisa de provisionadores) para seu projeto PHP com base no Vagrant.

Phpagrant_github_io_by_PHPagrant

Tem para todos os gostos: Puppet, Chef, Ansible. Você escolhe! Acesse lá, https://phpagrant.github.io/!

Docker

O novo “queridinho” do mundo da virtualização e conteinerização, o Docker, está evoluindo rápido e é importante você correr atrás do prejuízo e aprender sobre ele.

Docker_-_Build__Ship__and_Run_Any_App__Anywhere

Até a versão 1.2.x tinha um sério problema para os usuários de sistemas não Linux: o Boot2Docker, camada VM para permitir que usuários de OS X e Windows usem o Docker, não permitia usar pastas compartilhadas por padrão. Alguns hacks foram lançados (como o ótimo artigo do Chris Jones) , mas depois do lançamento da versão 1.3.0, tudo ficou mais fácil: foi embutido suporte para pastas compartilhadas e está mais simples para quem não usa Linux como máquina principal de desenvolvimento ter o Docker como parte do seu processo de trabalho.

Mas e sobre o PHP? Vamos lá! Algumas imagens disponíveis no https://registry.hub.docker.com/ para você se divertir:

  • oficialhttps://registry.hub.docker.com/_/php/ (falta FPM, mas já tem CLI e Apache com mod_php)

  • @brunoric: https://hub.docker.com/u/brunoric/ (brasileiro, aqui de São Paulo, especialista no Docker. Tem uma série de imagens PHP, vários sabores, até HHVM)

Além disso, seguindo a issue https://github.com/codeguy/php-the-right-way/pull/453, dá para ver que em pouco tempo o PHP: The Right Way (e o PHP: Do Jeito Certo) terá conteúdo sobre Docker e PHP (hoje eles já tem conteúdo sobre Vagrant).

Para quem quer ir direto colocar a mão na massa, o que estou fazendo:

  • Primeiro instalei o Docker (e, como estou num OS X, o Boot2Docker também. Comando para garantir que ele está ligado: boot2docker up)

  • [OS X apenas:] coloquei no meu ‘/etc/hosts’ o hostname ‘localdocker’ apontando para o IP 192.168.59.103 (esse ip é o que comando boot2docker ip mostra). Isso só é necessário para quem usa boot2docker, pois o Docker de verdade está rodando dentro de uma VM, com esse IP aí de cima. Quem está rodando no Windows deve ser algo parecido. Quem está rodando no Linux, não tem que se preocupar com isso, pois o Docker está usando o IP da sua máquina de verdade.

– Vou na pasta que seria o document root da minha aplicação (onde tem o front controller, geralmente index.php) . Como estou no OS X, essa pasta tem que estar dentro de /Users para usar o compartilhamento de pasta automático do boot2docker 1.3+. Ex:

$ cd /Users/eu/projetos/php123/

  • De lá, rodo o seguinte comando:

$ docker run --name my-php-webserver -p 8080:80 -v `pwd`:/var/www/html/ php:apache

O que aconteceu por trás do comando DOCKER RUN:

  • cria e já executa um container, baseado na imagem php versão apache

  • habilita o volume/disco internamente (dentro do container) como /var/www/html/ e externamente (na máquina host/vm boot2docker) como o resultado comando pwd (diretório atual)

  • redireciona a porta 80 interna (no container) para a porta 8080 externa (na máquina host)

É isso!

Quando precisar desligar o container, fazer os seguintes comandos:

  • $ docker ps -a (e copiar o CONTAINER ID)

  • $ docker rm CONTAINER_ID_QUE_VOCÊ_ACHOU_NO_COMANDO_ANTERIOR

Servidor embutido

Vai ter momentos que você não quer ou não pode ir para um dos modelos acima, Vagrant ou Docker. E nem quer instalar um servidor web completo (Apache, Nginx etc.) na sua máquina de desenvolvimento. O que fazer?

Se você tem o PHP CLI já instalado, é bom saber que desde a versão 5.4 é possível usar o servidor web embutido. Leia mais na documentação oficial.

PHP__Built-in_web_server_-_Manual

Então, na pasta onde seria o document root da sua aplicação PHP (onde ter o front controller, certo?), digite o seguinte comando:

$ php -S localhost:8899

A porta ali, no caso 8899, poderia ser qualquer uma de sua preferência. E você já tem um servidor web rodando servindo seu código PHP, no seu navegador disponível em http://localhost:8899. Fácil, não? Você ainda pode configurar algo como um .htaccess, a Lorna Jane Mitchell tem um artigo de 2012 falando do assunto. Mas, de novo, leia a doc oficial que você tem muita informação lá.

Considerações finais

Hoje você não é mais obrigado a instalar um servidor web como o Apache ou o Nginx apenas para testar uma aplicação PHP básica. O Servidor web embutido, desde o PHP 5.4 (março de 2012), fornece a estrutura básica para que, em desenvolvimento, você tenha um servidor mínimo.

Caso você precise espelhar o servidor de produção (hardware, sistema operacional e softwares utilizados), vá para o Vagrant, que te entrega isso de forma fácil com a virtualização, tanto para projetos genéricos quanto para projetos PHP.

E, se quiser estar na crista do onda, aplicando conteinerização também no ambiente de desenvolvimento, teste o Docker com PHP.

E fique a vontade de usar os comentários se quiser ajuda!

Até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Vagrant e seus plugins

E lá vamos nós falar de Vagrant!

vagrant-e-seus-plugins

Resumo da história dos plugins no Vagrant

Os plugins viraram cidadões de primeira classe na API v2 do Vagrant (antes eles até eram suportados com um pouco de mágica e um monte de requires no meio do seu Vagrantfile). Agora, como o Mitchell Hashimoto diz, o próprio Vagrant usa a API de plugins interna para boa parte de suas implementações, por isso, é possível ficar mais tranquilo de que as coisas funcionarão e que a interface é estável e bem suportada.

Não tenho nenhum plugin ainda desenvolvido, mas já utilizo vários para facilitar meu trabalho com o Vagrant. Então, vamos conhecer um pouco mais?

Como instalar plugins no Vagrant

A documentação do Vagrant sobre plugins está bem completa nesse ponto, e é bem fácil: nada mais do que rodar: $ vagrant plugin install NOME-DO-PLUGIN.

Exemplo para instalar o vagrant-aws:

$ vagrant plugin install vagrant-aws.

Os plugins são na maioria mantidos pela comunidade, e por isso não existe uma listagem oficial. No entanto, existe uma página na wiki do projeto com os plugins marcados pelos usuários, sugiro que visite para buscar os que sirvam para o seu caso de uso.

Quer uma dica de alguns para começar? Veja abaixo:

Plugins Vagrant que não podem faltar para mim

Bindler

Para quem conhece o Composer no mundo PHP, o Bundler no mundo Ruby ou o Bower no mundo FrontEnd, é fácil entender o que esse plugin faz e também a vantagem de usá-lo, o Bindler.

Ele permite que você crie um arquivo na raiz do seu projeto Vagrant (na mesma pasta onde você coloca o seu Vagrantfile) para distribuição, deixando claro para seus usuários que plugins são as suas dependências.

Quando alguém for usar o seu projeto, executará $ vagrant plugin bundle antes do $ vagrant up, e o Bindler se encarregará de instalar as dependências que faltarem. Se o usuário já tiver os plugins instalado globalmente, estes serão usados, senão, o Bindler instalará o que faltar localmente para o projeto apenas. E quando o usuário fizer o $ vagrant destroy tudo voltará ao que era antes.

Vagrant Cachier

O Cachier é aquele cara que faz você se perguntar: como conseguiu viver sem ele até agora! Ele faz o cache dos pacotes Apt que você instala na suas distribuições Debian-like (Ubuntu inclusive) entre todas os projetos que você tiver baseado em uma box.

Assim, ele acelera (e muito!!!) a instalação das suas dependências, pois, se um pacote já tiver sido baixado naquela versão específica em um outro projeto, será usado o cache em vez de ir até o repositório oficial do Ubuntu, por exemplo.

Vagrant HostManager

Vai chegar o momento em que apenas definir um IP na opção :private_network do Vagrantfile, ou mesmo a redirecionamento de porta via :forwarded_port, não será mais suficiente para testar seu projeto (por diversos motivos isso pode acontecer. Acredite, quando você chegar nesse nível você vai lembrar das minhas palavras 😉 ).

Nesse momento você vai procurar uma forma de configurar o seu arquivo HOSTS, /etc/hosts (nos sistemas *nix) ou %windir%\system32\drivers\etc\hosts (no Windows), para que endereço do seu Vhost do Apache fique disponível tanto internamente nas máquinas (Guests) quanto a partir do seu sistema principal (Host). Qual é o caminho normal para fazer isso? Sim, editar manualmente seu arquivo HOST em um monte de lugares.

Aí que entra o plugin HostManager: com base numa pequena configuração do seu Vagrantfile ele já configura tudo isso para você. Existem alguns outros que fazem o serviço de forma parecida, mas foi com ele que me adaptei mais.

Considerações finais

Os plugins foram uma inclusão importante no ecossistema do Vagrant, e como viram, não é difícil de usar os que já estão disponíveis. Esse artigo está longe de te dar o caminho completo para usar as ferramentas, mas já te inicia e mostra onde você pode conseguir mais informações. Procure conhecer e testar o máximo que você conseguir pois assim vai ser fácil de tomar a decisão de usar ou não um deles em seus futuros projetos.

E fique a vontade de usar os comentários se quiser ajuda!

Até mais!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Build e Integração Contínua no PHP com Composer, Phing, Travis-CI e Scrutinizer-CI

Olá, pessoal,

Há tempos que não fazia uma limpeza no meu Github, seja para excluir projetos que não fazem mais sentido, forks que não ia mais utilizar, ou mesmo para atualizar algum repositório e me lembrar de tudo que venho estudando desde que conheci o Github (segundo o site dos caras, outubro de 2010).

  

E foi no meio dessa limpeza (na verdade bem no começo mesmo :-) ) que achei o https://github.com/rogeriopradoj/ManoWars, fork de um projeto criado pelo Rafael Dohms e pelo Augusto Pascutti há muito tempo para ensinar sobre Testes Unitários e Integração Contínua.

Foi aí que pensei: porque não dar uma relembrada no assunto, e também atualizar com coisas que tenha aprendido nesse período (poxa, são quase 3 anos!)?

Phing???

Logo Phing

Muita coisa ainda não havia tocado, caso do Phing, que o Hussani e o Duodraco já haviam apresentado mais de uma vez em palestras. Também não estava muito habituado com as ferramentas para geração de relatórios de métricas, como o PHPMD, ou o PDepend.

Mas aí estava a graça, um bom desafio! E com a ótima estrutura que o Dohms e o Pascutti haviam deixado, não foi tão difícil começar.

Composer

Composer logo

A primeira coisa que fiz foi usar o Composer para gerenciar as dependências do projeto.

Aqui uma decisão tinha que ser tomada: o projeto foi todo baseado em PHP 5.2+, e eu poderia continuar deixando essa versão como a mínima necessária. Só que muitas das ferramentas de métricas e o próprio PHPUnit que hoje está disponível via Composer é apenas 5.3+. Então decidi subir para 5.3 a dependência mínima.

Como o Composer além de gerenciar as dependências também gera um autoloader completo (tanto com o código do meu projeto quanto das dependências), pude retirar sem dó o Zend/Loader que estava no projeto, pois ele não era mais necessário.

E com um mágico $ composer install estava lá: todas as dependências na pasta vendor, um autoloader funcional completo, e o melhor, todas as ferramentas binárias (PHPUnit, PHPPdepend etc., e o próprio Phing) já disponíveis também na pasta vendor/bin.

É, o Composer é uma mão na roda!

E lógico, com o PHP 5.4+ com servidor web embutido, foi brincadeira de criança subir testar a aplicação rodando no navegador, só com um $ php -S localhost:8080 -t public.

Estrututura de pastas e arquivos

Como o Composer coloca todas as dependências dentro da pasta vendor na raiz, e é meio que padrão os projetos PHP que vejo deixarem uma estrutura baseada na raiz também, mudei um pouquinho as pastas de lugar. A maior mudança foi colocar as pastas que estavam dentro de ManoWars na raiz, assim a hierarquia ficou um pouco menor.

  • /libs: contém o código da aplicação
  • /public: o document root do servidor web
  • /tests: testes unitários
  • init.php: bootstrap da aplicação (usado tanto na aplicação web quanto nos testes)

phpunit.xml.dist

Já havia lido sobre a vantagem de usar o phpunit.xml.dist no artigo [Best practice] How to ship PHPUnit configuration do test.ical.ly, e até já mandei um Pull Request para o Ophportunidades sobre isso.

Então foi um passo para criar um arquivo de configuração para o PHPUnit, já desde o começo um .dist.

Vantagem: agora para rodar o phpunit não é preciso entrar na pasta tests, é só rodar a partir da raiz. Outro ponto, não é mais necessário o arquivo AllTests.php, pois a definição da suíte de testes é feita também nesse arquivo de configuração.

PHP CodeSniffer

Uma task do Phing que não estava sendo executada era a de verificação do padrão de codificação, com o phpcs. Pensei em colocar o padrão PSR2 logo de cara, mas como o projeto foi feito a muito tempo, muitos erros iriam aparecer. Preferi deixar com o padrão Zend que foi provavelmente o que o Dohms e o Pascutti usaram.

Na minha lista de tarefas está evoluir o padrão para PSR2.

Outras ferramentas

Todas as ferramentas que estão sendo usadas para métricas, testes e build estão no composer.json, dê uma olhada lá, ok?

README

E no LEIAME do projeto a principal mudança foi trocar o formato para Markdown (na verdade o GFM) que é uma beleza para escrever e o Github já faz a renderização muito bem para HTML.

Ferramentas de Integração Contínua Online (Travis e Scrutinizer)

Depois de todos os pequenos ajustes, era hora de mexer de verdade no projeto.

A primeira coisa que percebi é que tinham poucos testes falhando. Tinha a ver com a API do PHPUnit ter mudado, e com um teste que esperava nulo, mas na verdade o método retornava um inteiro. Fiz o ajuste nos testes e eles passaram a funcionar.

Agora era hora de resolver todos os outros problemas do código: padrão de codificação, aumentar cobertura de testes, complexidade, etc. etc., tudo relacionado a QA/Garantia de Qualidade. Também analisar os relatórios gerados, uma parte interessante que nunca tinha olhado mais de perto.

Mas por que não ser um pouco poser e colocar um monte de badges no projeto? Esses badges seriam para mostrar a evolução do projeto, e fui atrás das ferramentas online que me permitiriam isso

Travis

Logo do Travis

Comecei pela mais conhecida, o Travis-CI, que já tinha usado em outros projetos. Nele começei colocando o PHPUnit para rodar, nas 3 últimas grandes versões do PHP, 5.3, 5.4 e 5.5.

O Travis conta um conceito interessante de matriz de build, onde você cruza algumas configurações e o build é feito em todas as combinações dela. Isso me ajudou no passo seguinte.  O Travis já tem um executável do PHPUnit disponível para usarmos, mas eu gostaria de rodar o PHPUnit instalado pelo Composer também. Fácil: criei uma variável de ambiente RUN, que no primeiro momento era definida como phpunit, e no segundo momento como vendor/bin/phpunit. E o Travis se encarregou de rodar os builds 6 vezes (3 versões do PHP x 2 PHPUnit diferentes).

No fim, coloquei mais uma definição para a variável de ambiente RUN como vendor/bin/phing, e o Phing inteiro foi rodado lá no Travis, muito bacana!

Scrutinizer

Logo do scrutinizer

Só um problema: o Travis sozinho não avalia os relatórios gerados. Foi aí que peguei o Scrutinizer-CI, que já havia também usado anteriormente, mas quando o Alexandre Eher lembrou dele no PHPSPub de Agosto, vi que era uma boa ideia usá-lo de verdade.

Depois de bater um pouco de cabeça, consegui fazer a maioria das métricas serem executadas, e no fim, o que mais queria: os badges!!!

Travis
Scrutinizer – Quality
Scrutinizer – Coverage

E para renderizar o README um pouco melhor, e lógico que usando outra ferramenta online, fui de DocumentUp.

É isso aí, pessoal, escrevi bastante e tem bastante coisa para fazer ainda.

Se quiser acompanhar, lá no https://github.com/rogeriopradoj/ManoWars.

Até mais!

 

Este artigo foi publicado originalmente em RogerioPradoJ.com.

E o site do PHPSP voltou!

Olá, pessoal,

Voltar aqui para dizer que o site do PHPSP, http://www.phpsp.org.br, voltou ao ar e cheio de conteúdo!

O processo começou em março no Hackathon PHPSP que ocorreu no iMasters, e durante esses meses veio sendo feito a passos largos (mudança de hospedagem, criação do tema, novos colaboradores, etc etc.).

E na reunião de 08/08/2013 do grupo foram fechadas uma série de novidades!

Eventos, encontros, artigos novos, tudo beleza!

Tem até um artigo meu lá, http://phpsp.org.br/index.php/pra-nao-dizer-que-nao-falei-de-vagrant/, Pra não dizer que não falei de Vagrant.

É isso aí, como diz o Duodraco, We rock!!!

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Introdução do MongoClient

Estou fazendo o curso de MongoDb oficial da 10gen. A ideia da tradução desse artigo saiu de lá.

Tradução livre do Introducing MongoClient, disponível em http://blog.mongodb.org/post/36666163412/introducing-mongoclient

Em 27 de novembro de 2012 foram disponibilizadas pela 10gen versões atualizadas da maioria dos drivers para MongoDB mantidos oficialmente, com novos padrões para verificação e reportagem de erros. Veja abaixo mais informações sobre as mudanças, e consulte a documentação dos drivers para mais detalhes.

Nos últimos anos, tornou-se evidente que os padrões anteriores no comportamento do MongoDB (onde por padrão as mensagens de escrita não esperavam  um código de retorno do servidor) não eram intuitivos e causavam confusão com os usuários do MongoDB. A 10gen queria melhorar isso com o mínimo de problemas para as aplicações MongoDB que já estivessem em produção.

História

Primeiro, seria interessante compartilhar a história por trás do comportamento padrão anterior, e por que e como ele foi alterado.

O comportamento antigo está ligado ao início da 10gen, antes dos fundadores terem imaginado o MongoDB como uma base autônoma. Quando a 10gen começou, no outono de 2007, eles se propuserem a construir uma plataforma completa como uma pilha de serviços, com o MongoDB como a camada de dados. Era um sistema totalmente hospedado (continua sendo de código aberto), que englobava um load balancer, uma aplicação auto-escalável e uma camada de dados. A parte da aplicação era um ambiente completo em JavaScript do lado servidor.

Toda requisição na 10gen era uma requisição http. Você poderia imaginar um controller para fazer alguma análise de usuários funcionando assim:

URL:  http://foo.10gen.com/show?sect=sports&page=blog1

CODE:

db.sect_views.update(
{ _id : db.getParameter( “sect” ) } ,
{ $inc : { count : 1 } } , /*upsert*/true );
db.page_views.update(
{ _id : db.getParameter( “page” ) } ,
{ $inc : { count : 1 } } , true );

As escritas naquela sistema não esperavam individualmente por uma resposta do banco de dados. No entanto, o próprio servidor da aplicação verificava sempre o banco de dados por algum erro que ocorresse durante todo o carregamento da página (usando getLastError e getPrevError), assim o usuário/sistema poderia ser notificado sobre algum problema. É claro que os desenvolvedores também poderiam chamar a função getLastError sempre que quisessem. Isso funcionava muito bem na plataforma, pois a 10gen era capaz de controlar completamente o padrão de acesso.

Em janeiro de 2009, eles decidiram, por um série de razões, apenas focar na camada de dados (MongoDB). Naquela época, um certo número de pessoas vinha usando o MongoDB em produção por quase um ano como parte do projeto completo, e muito mais pessoas estavam bem interessadas em usá-lo de forma independente.

Durante os meses seguintes, eles escreveram as implementações iniciais dos drivers Java, Python, Ruby e PHP. Todos esses drivers usavam o mesmo protocolo de rede que o servidor da aplicação original, com operações de escritas não síncronas. Isso parecia natural para eles devido ao tempo passado no background, mas claramente não era tão intuitivo para novos usuários do MongoDB que nunca haviam usado o pacote completo.

Novo Comportamento

Avançando, o padrão claramente tinha que ser: esperar o banco de dados acusar todas as escritas, o que é muito mais intuitivo. No entanto, apenas mudar o padrão, levaria à quebra da compatibilidade com os aplicativos em produção.

A mudança que eles fizeram foi adicionar uma nova classe de conexão, de nível superior, em cada um dos drivers. Por exemplo, no Java, anteriormente se fazia assim:

Mongo mongo = new Mongo( “mongoserver” );

Aquela classe, Mongo, será mantida como o padrão antigo, e se torna obsoleta/deprecated.

Para novos códigos, você fará:

MongoClient mongo = new MongoClient( “mongoserver” );

que terá como padrão 1 no WriteConcern. Todo o resto será do mesmo jeito.

A classe antiga será mantida por um tempo (mas não para sempre), para que não seja quebrado agora o código antigo. Um outro benefício, todo driver usará o MongoClient, assim pela primeira vez ao menos no nível superior das classes se terá o mesmo nome sendo compartilhado. Toda a documentação, tutoriais e códigos de exemplo foram alterados apropriadamente.

Mais informações

  • Para baixar os drivers, documentações e tutoriais, visite a página de drivers na wiki do MongoDB.
  • Para reportar bugs e para pedidos de funcionalidades, visite jira.mongodb.org.
  • Para qualquer outro feedback, deixe um comentário no post no forum de usuários

Eliot e a Equipe MongoDB agradecem o suporte contínuo e feedback da comunidade sobre o MongoDB.

 —

Valeu, pessoal!

 

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Screencast – Contribuindo para um projeto open source no Github

Olá, pessoal!

Primeiramente, feliz 2013, e vamos começar esse ano com um screencast, meu primeiro!

Será que todo mundo da comunidade  já contribui ou contribui para um projeto Open Source (seja um já existente, ou criando um)?

Eu só comecei a ajudar depois do projeto/promoção http://sou.phpsp.org.br/ do PHPSP, que infelizmente já acabou.

Mesmo assim continuei me envolver nos projetos e, posso dizer: você EVOLUI MUITO dessa forma!

Esse meu primeiro screencast (já me desculpando antecipadamente pela qualidade, hehehe) mostra o processo de contribuição para incluir a integração ao http://travis-ci.org/ no projeto do João Batista Neto, o https://github.com/netojoaobatista/maestro.

Quis montar ele para ajudar o pessoal que ainda não começou a contribuir talvez por achar que é muito difícil, ou por não ter uma ideia de como começar. Com certeza a inspiração veio do projeto iMasters + Comunidade PHP que fez o Hangout de uma aplicação sendo desenvolvida ao vivo!

Digam o que acharam, ok?

Até mais!

 

Link para o vídeo: http://www.youtube.com/watch?v=CVXhZIIg3zU

 

Este artigo foi publicado originalmente em RogerioPradoJ.com.

Como atualizar a versão do PHP no Mac OSX Mountain Lion

Olá, pessoal Venho usando o Vagrant (oficial, tradução e meu github) faz um tempo, para diminuir o número de coisas instaladas no meu notebook[bb], mas precisava atualizar a versão do PHP que tinha instalado por padrão no meu Mac OSX.

Participando do projeto do iMasters, oPHPortunidades (veja os hangouts), precisei rodar alguns comandos básicos no console, usando o excelente Composer, mas por não ter a última versão do PHP ficava difícil acompanhar o pessoal. Principalmente pela funcionalidade do servidor web embutido no PHP 5.4, que economiza bastante tempo para não precisar de configurar um Apache apenas para teste de uma aplicação.

É fato que usando o Vagrant poderíamos deixar preparado algumas receitas básicas, Puppet ou Chef, para deixar subir uma máquina com a última versão do PHP, mas a possibilidade abrir um terminal em um diretório com um projeto mínimo rodando apenas um php -S localhost:8080 em vez de um vagrant init, subl Vagrantfile, vagrant up, vagrant ssh etc etc era interessante.

Foi nesse momento que fui procurar uma opção de atualizar a minha versão global do PHP, do 5.3.15 que é a que vem instalada no Mac OSX Mountain Lion, para a versão mais nova estável, 5.4.8 quando esse artigo foi escrito. Quando comecei a usar o Mac, em agosto 2011, procurei uma solução parecida com a que usava no Windows, o XAMPP, e tinha encontrado o MAMP e o próprio XAMPP (que eu tinha usado no meu tempo de Ubuntu também também tem versão Mac). Mas não queria mais utilizar uma opção desse tipo. Queria ter a última versão realmente instalada e acessível a partir da linha de comando.

O primeiro lugar onde fui olhar foi o manual do PHP, que agora está um pouco mais atualizado, mas até quando eu vi (setembro 2012) só tinha uma sugestão: compile o PHP usando as instruções para UNIX. Escolhi não usar essa opção.

Um tempo atrás o Fábio Ribeiro perguntou no Twitter como o pessoal estava montando o ambiente PHP no OSX, e na época ele recebeu a indicação do Homebrew. Essa seria uma opção interessante.

Enquanto estava ajudando na tradução do PHP The Right Way, o PHP Do Jeito Certo, verifiquei que já existia uma pacote binário da versão mais nova do PHP 5.4, a http://php-osx.liip.ch/, que era até a versão recomendada pelos criadores do site. Mais uma boa opção para escolher.

Enfim, fui procurar um maior embasamento para minha escolha final: perguntar no Facebook, no grupo PHP Brasil. Lá vários caras que entendem do assunto deram suas opiniões e o mais legal: me deixaram com mais dúvidas ainda!!! Isso porque surgiram mais umas opções lá ainda não conhecia: o php-build e o phpenv.

O php-build é uma cara para compilar o php automaticamente a partir do repositório oficial do PHP, e o phpenv é uma ferramenta para definir qual versão do PHP você irá utilizar no caso de você ter instalado várias opções paralelamente. No fim, foi essas duas opções juntas que escolhi usar e vou mostrar aqui como fiz:

  1. Instalar o wget, usando o homebrew (ele é usado pelo php-build, mas você pode escolher outra forma de instalar o wget)
  2. Executar o brew install pkg-config curl freetype gettext jpeg libpng mcrypt zlib re2c tidy openssl pcre libxslt xmlrpc-c regex-opt exif json-c gd libiconv base64 icu4c lemon gmp t1utils mhash expat, usando o homebrew (pelo menos na versão do PHP 5.4.8 pelo php-build ele pediu algumas dependências, depois que instalei esses pacotes o problema parou de acontecer aqui)
  3. Instalar o php-build (usando a instalação padrão com o git, http://chh.github.com/php-build/)
  4. Instalar o phpenv (seguir o caminho que foi feito para instalar o php-build, depois na pasta bin, executar o phpenv-install.sh)
  5. Atualizar o seu PATH seguindo as orientações da saída do comando phpenv
  6. Instalar a versão que você quer do PHP, seguindo a instrução daqui: https://github.com/CHH/phpenv#description
  7. Rodar o phpenv rehash, o phpenv global com a versão escolhida e pronto!

Se você executar um php -v antes de fazer todos os comandos, você deve ver a sua versão do PHP como 5.3.15. Depois dos comandos acima, se executar um php -v deve ver a versão do PHP mais nova que você instalou (no meu caso ficou o PHP 5.4.8).

É isso aí pessoal, quem ficar com dúvidas pode perguntar nos comentários.

Até a próxima.

Este artigo foi publicado originalmente em RogerioPradoJ.com.