Polka Tables, originally uploaded by markrocky.

From our photography excursion (with Harvest Digital) on the South Bank using “Lomolitos” (mini Lomos), on Wednesday evening…

Polka Tables, originally uploaded by markrocky.

From our photography excursion (with Harvest Digital) on the South Bank using “Lomolitos” (mini Lomos), on Wednesday evening…

We are a small development team, at Harvest Digital, handling multiple tasks throughout the day, across different environments and projects. It makes for an exciting challenge. Our roles/ skills are clearly defined and our small size means we can react quickly to change, with little margin for communication errors and so on (see Getting Real and Less is more: Jumpstarting Productivity with Small Teams). But, when it comes to deploying to a staging or production server, I am ashamed to admit that we had often introduced a huge potential for human error by doing much of the work manually. Each project is different and so there is no consistent deployment process across the board.

Deployment is often the last step in the process to get any attention and it is one that can be unnecessarily tedious and prone to error. With more agile development projects, where deployments may be required several times a day, we obviously cannot afford the time nor the potential mistakes that may be made by manually deploying a project.

At its simplest level, deployment may just involve making sure that the target server (i.e. staging or production) has the latest revision of files from the project’s source control repository (we use SVN). But factor in automated tests and database migration and you can see how easily things can go wrong. Especially if you are deploying several times a day. You need to automate as many steps in the process as possible, thereby eliminating any manual tasks that introduce potential error and duplication.

Whenever we reach a point in a project where the code can be considered stable, we should tag it in SVN as a release. This gives you the ability to deploy a particular release based on its tag, instead of just the latest revision in the repository. By convention you never create revisions in the tag folder – tags are simply named snapshots of the source repository. We typically use version numbers as tags with some scheme based on feature-set or milestone and release date that can be ordered alpha-numerically e.g. “rel_belfast_2.04″. This allows us to say with certainty what is deployed at any one time, without having to scan logs etc. Tags give context to a release name (you can easily associate the release with project milestones) that revision numbers and timestamps do not. Tags are usually kept in a ‘tags’ subfolder, in the top level of the repository.

For a while now at Harvest, we’ve been working with symfony – an excellent PHP framework – that includes a few tools to help simplify the deployment process (such as Pake). These tools allow for remote syncronisation of files with rsync (the benefits of synchronisation over standard FTP are much touted elsewhere) via SSH (with the shell command: e.g.

) and semi-automate the build process (including database schema changes, data dumps etc: e.g.

) by using Pake on the target machine.

But there is still a lot of room for improvement, particularly when it comes to database migrations and SVN integration. Plus, symfony is not our only set-up. We need an automated deployment process that can be applied across all our projects. This is where I’ve previously seen shell scripts being used but Phing can do much of this heavy lifting work for us, as it has many standard deployment tasks built-in to it. According to the Phing blurb:

Features include file transformations (e.g. token replacement, XSLT transformation, Smarty template transformations), file system operations, interactive build support, SQL execution, CVS operations, tools for creating PEAR packages, and much more.

Phing (PHing Is Not GNU make) is a project build system based on Apache Ant and is available through the PEAR installer. If you use

on Phing, it’ll grab, funnily enough, all the dependencies. But most are good packages (e.g. PHPUnit, PHPdoc and VersionControl_SVN). It can be used in a multitude of ways, including unit testing, creating docs, running SQL – which allows us to keep database schema changes in version control. The beauty of Phing is everything can be configured easily through the build.xml file (and then further with properties files) – so that the project’s deployment configuration can be kept in version control too.

In short, we love this thing called Phing!

For more detail on advanced tasks such as database migration take a look at these posts from Federico Cargnelutti and Dave Marshall.

We are a small development team, at Harvest Digital, handling multiple tasks throughout the day, across different environments and projects. It makes for an exciting challenge. Our roles/ skills are clearly defined and our small size means we can react quickly to change, with little margin for communication errors and so on (see Getting Real and Less is more: Jumpstarting Productivity with Small Teams). But, when it comes to deploying to a staging or production server, I am ashamed to admit that we had often introduced a huge potential for human error by doing much of the work manually. Each project is different and so there is no consistent deployment process across the board.

Deployment is often the last step in the process to get any attention and it is one that can be unnecessarily tedious and prone to error. With more agile development projects, where deployments may be required several times a day, we obviously cannot afford the time nor the potential mistakes that may be made by manually deploying a project.

At its simplest level, deployment may just involve making sure that the target server (i.e. staging or production) has the latest revision of files from the project’s source control repository (we use SVN). But factor in automated tests and database migration and you can see how easily things can go wrong. Especially if you are deploying several times a day. You need to automate as many steps in the process as possible, thereby eliminating any manual tasks that introduce potential error and duplication.

Whenever we reach a point in a project where the code can be considered stable, we should tag it in SVN as a release. This gives you the ability to deploy a particular release based on its tag, instead of just the latest revision in the repository. By convention you never create revisions in the tag folder – tags are simply named snapshots of the source repository. We typically use version numbers as tags with some scheme based on feature-set or milestone and release date that can be ordered alpha-numerically e.g. “rel_belfast_2.04″. This allows us to say with certainty what is deployed at any one time, without having to scan logs etc. Tags give context to a release name (you can easily associate the release with project milestones) that revision numbers and timestamps do not. Tags are usually kept in a ‘tags’ subfolder, in the top level of the repository.

For a while now at Harvest, we’ve been working with symfony – an excellent PHP framework – that includes a few tools to help simplify the deployment process (such as Pake). These tools allow for remote syncronisation of files with rsync (the benefits of synchronisation over standard FTP are much touted elsewhere) via SSH (with the shell command: e.g.

) and semi-automate the build process (including database schema changes, data dumps etc: e.g.

) by using Pake on the target machine.

But there is still a lot of room for improvement, particularly when it comes to database migrations and SVN integration. Plus, symfony is not our only set-up. We need an automated deployment process that can be applied across all our projects. This is where I’ve previously seen shell scripts being used but Phing can do much of this heavy lifting work for us, as it has many standard deployment tasks built-in to it. According to the Phing blurb:

Features include file transformations (e.g. token replacement, XSLT transformation, Smarty template transformations), file system operations, interactive build support, SQL execution, CVS operations, tools for creating PEAR packages, and much more.

Phing (PHing Is Not GNU make) is a project build system based on Apache Ant and is available through the PEAR installer. If you use

on Phing, it’ll grab, funnily enough, all the dependencies. But most are good packages (e.g. PHPUnit, PHPdoc and VersionControl_SVN). It can be used in a multitude of ways, including unit testing, creating docs, running SQL – which allows us to keep database schema changes in version control. The beauty of Phing is everything can be configured easily through the build.xml file (and then further with properties files) – so that the project’s deployment configuration can be kept in version control too.

In short, we love this thing called Phing!

For more detail on advanced tasks such as database migration take a look at these posts from Federico Cargnelutti and Dave Marshall.

...recently brought to my attention on epicurious.com

The horizontal nav features your usual rollover-and-drop-down type interactivity. Nicely done with the added bonus of having a regularly changing 'featured item' underneath it that might be of interest.


Yummy!

However, the surprise happens when you click the little arrow to the right of the category name....et voila.... all the navigation under that category is shown in one fell swoop.

A nice way to personalise the navigation to suit the user's individual tastes.

Now, all this talk of food is making me hungry.

...recently brought to my attention on epicurious.com

The horizontal nav features your usual rollover-and-drop-down type interactivity. Nicely done with the added bonus of having a regularly changing 'featured item' underneath it that might be of interest.


Yummy!

However, the surprise happens when you click the little arrow to the right of the category name....et voila.... all the navigation under that category is shown in one fell swoop.

A nice way to personalise the navigation to suit the user's individual tastes.

Now, all this talk of food is making me hungry.

More book covers, this time of the vintage variety.
Its pretty much acejet170's fault that I developed a sudden penchant for old Penguins. I love looking at how different designers introduced new rules to create families of books over the decades. Many of them feel so contemporary... a good 50 years after they were published.



Left: Birds of the Sea by R.M. Lockley, published 1945, Cover Designed by Enid Marx, who it turns out was a textile designer, illustrator and expert in wood block printing.

Right: Flowers of the Woods by E.J. Salisbury published 1946, Cover Designed by Rosmary and Clifford Ellis, who did these lovely posters for London Underground in the 1930's.



Left: Poisonous Fingi by John Ramsbottom, Published 1945, Cover designed by Joy Jarvis. I would love to find out more about this designer, but so far have come up empty handed..

Right: Penguin Modern Stories 3, Published 1969, Cover designed by David Pelham. read more about Pelham's history with Penguin on the CR blog

More to follow one day...

When at a shin-dig just the other week about 7 people, other than myself, were talking the talk about the importance of designing good customer experiences.