We've started using Travis CI on one of my projects to run some build processes to check that everything looks good before we merge/deploy code. One thing I ran into quite quickly was that I wanted to install phing in order to use the build scripts we already have and use elsewhere, but that it isn't provided by default by Travis CI.
I'm a huge fan of Phing and use it regularly for build and deployment tasks. Often, I'll ask about a plugin that I wish existed, and get a very courteous "patches welcome" from the nice people in the #phing channel on freenode. This has happened a few times, so I thought I should probably look at how to make a new phing plugin, this article shows you how to make the simplest thing I could think of: a simple "hello world" plugin. Continue reading
This post is mostly about a tutorial I will be delivering at PHPNW on October 5th in Manchester, UK, and why I think a tutorial that contains no PHP belongs at a PHP conference
In October, I'll be delivering a tutorial at the mighty PHPNW Conference which contains very little PHP. Why? Because I think, as developers, it's our other professional skills that suffer. As a consultant, I work with lots of different teams, and it is very rare for code to be the problem (and the one time it was, it wasn't the only problem!).
In web development, our biggest challenges are not writing code, we can do that. But getting the code safely from one place to another, with many people's work preserved, having our platform(s) correctly configured and understanding how to use them, making use of the tools in the ecosystem which will help us improve the quality of our code; these are the big challenges we face, and that's why I proposed this workshop and why I think all these topics are important. Continue reading
Someone emailed me recently, having read my book and wanting some advice. Here's a snippet of his email:
So here's my problem.
We dont know deployment. We work from same copy on one test server through ftp and then upload live on FTP.
We have some small projects and some big collaborative projects.
We host all these projects on our local shared computer which we call test server.
All guys take code from it and return it there. We show our work to clients on that machine and then upload that work to live ftp.
Do you think this is a good scenario or do we make this machine a dev server and introduce a staging server for some projects as well?
I wrote him a reply with some suggestions (and my consulting rate) attached, and we had a little email exchange about some improvements that could fit in with the existing setup, both of the hardware and of the team skills. Then I started to think ... he probably isn't the only person who is wondering if there's a better way. So here's my advice, now with pictures! Continue reading
disclaimer: I am not underestimating the universe's ability to produce idiots, the point I'm trying to make is that I haven't managed to make any deploy mistakes using this approach. Yet.
Once upon a time, a long time ago, I went onto a conference stage for the very first time and said that I thought I might be the world's ditsiest PHP developer. I actually still think that is pretty true, and if you work with me then you will know that I mostly break and fix things in approximately equal measure. With this in mind, when I launched my own product recently (BiteStats, a thing to automatically email you a summary of your analytics stats every month), I knew that I would need a really robust way of deploying code. I've been doing a few different things for a few years, and I've often implemented these tools with or for other organisations, but I don't have much code in production in my own right, weirdly. I decided Phing was the way to go, got it installed, and worked out what to do next.
I've written before about a simple way of patching database versions and there's a much more comprehensive article from Harrie on TechPortal as well. I often find though that projects with patching strategies are missing the scripts to apply these automatically when the code is deployed, so I thought I'd share mine.
My current project (BiteStats, a simple report of your google analytics data) uses a basic system where there are numbered patches, and a
patch_history table with a row for every patch that was run, showing the version number and a timestamp. When I deploy the code to production, I have a script that runs automatically to apply the patches.