In my Beyond Frameworks talk, I explained how a component-based architecture can help answer some of the important (i.e. expensive!) questions you might face when creating long-lived apps that rely on a PHP framework. In this series of blog posts, I’m going to look at how to go about creating and working with components.
In my last article, I looked at how to publish your own PEAR channel, and why today that’s the best option for you and your projects. It takes about 10 minutes to publish your first PEAR channel, thanks to Fabien’s work on creating Pirum.
But what is it like to actually work with your own PEAR channel on a long-term basis? What are the things you could do to make things as easy as possible?
Tip 1: Local Copy Of Your PEAR Channel
Sometimes, you develop a component for the sake of it, but most of the time, you end up writing your components and the app that needs them side by side. This is what happened with phix et al, and behind the scenes here it is also what is happening with the components for my example app called sental.
When that happens, no matter how focused and skilled your unit testing is, you’ll want to release preview versions of your component, try them in your app, and then go back to your component and tweak things … all before you’re ready to share the next release of your component via your PEAR channel. This is what the ‘alpha’ and ‘beta’ stability flags in package.xml were originally designed for, but it’s more pragmatic to have a local, private copy of your PEAR channel on your dev box, and leave those stability flags well alone.
Here are the steps you need to follow to setup your own private copy of your PEAR channel on a Linux box:
- Setup Apache on your dev box with a virtual host to publish your PEAR channel, just like you have done on your public webserver.
- Use pirum to create your PEAR channel’s files on your dev box (or, even better, see Tip 3 below).
- Edit /etc/hosts to have the fully-qualified domain name for your PEAR channel point to IP address 127.0.0.1.
With this done, every time you use the PEAR installer on your dev box to install something from your PEAR channel, the PEAR installer will actually download your component from your private copy of your PEAR channel. You can keep putting new copies of your component onto this private copy of your PEAR channel until you’re satisfied with it, and it doesn’t matter that you’re not actually bumping the version number of your component each time you do so, because only you are affected.
And when you’re ready to send this new version out into the world, you just need to tag the release in source control, and then upload your private copy of your PEAR channel to your public webserver.
(Btw, if you do a lot development disconnected from the internet like I do, having a local copy of your PEAR channel is pretty much a must!)
Tip 2: Tag Your Releases
Once you’ve decided that your component is ready to share with everyone on your PEAR channel, that’s the time to tag your release in source control. It’s dead easy to do, and it gives you and anyone else who takes over maintenance of your code a record of what was in each release.
Here’s how to do it in git.
stuart:~/Devel/sental/repustateApi$ git tag -a -m 'Release 0.1.0' 0.1.0 stuart:~/Devel/sental/repustateApi$ git push --tags origin master
If you’re publishing on GitHub, you can then go to your component on there and forever more see your code for that release. Here’s the repustateApi component at version 0.1.0 on GitHub, as a real example of tagged code. An even better example is Sebastian Bergmann’s PHPUnit project, where at the time of writing there are 193 tags to see!
As an aside, we really should be digitally signing these tags, but that is a topic in its own right for a later blog post!
Tip 3: Publish Your PEAR Channel Via Source Control
It isn’t just the code for your components that can be tracked via source control; there is nothing stopping you from publishing your PEAR channel via source control too. pear.gradwell.com is our public PEAR channel, and we have a pear.gradwell.com repo up on GitHub for it.
This makes it extremely easy to publish new packages to our PEAR channel. On my dev box, I add a new release to source control like this:
stuart:/var/www/pear.gradwell.com$ git clone firstname.lastname@example.org:Gradwell/pear.gradwell.com.git stuart:/var/www/pear.gradwell.com$ pirum add . ~/Devel/repustateApi/dist/repustateApi-0.1.0.tgz stuart:/var/www/pear.gradwell.com$ git add -i stuart:/var/www/pear.gradwell.com$ git commit -m 'Added repustateApi-0.1.0' stuart:/var/www/pear.gradwell.com$ git push origin master
… and then I SSH into our public webserver, and simply do:
stuart:/var/www/pear.gradwell.com$ git pull
This is actually a very handy setup when you have more than one developer publishing packages. Each of your developers merges their new releases into source control, so that no-one trips over each other (very important in a distributed team), and everyone can clearly see who has published what.