What does a good Phing workflow look like?

Question

I'm trying to get into the mindset of CI and have been playing with Phing this weekend. It all seems straight forward enough to use and have many examples going already.

However something that still puzzles me is how people actually use it. That is, I'm not looking for what tests you do, but instead a suggested work flow using Phing, at what stage do you activate it, at what stage in the development cycle is it actioned.

For example, we have several websites, currently we edit the source locally and on save upload to the live site (I know how bad this is...), we do some quick testing and make sure the code works as planned. If so we commit to the repos and carry on. If not, we can roll back or edit undo and resave. Whilst this now seems crazy the simplicity has worked well for us.

We now have a small team however, so I'm trying to push Phing into this process, to get all the added benefits of the linting/sniffing/mess detecting e.t.c. however I can't figure the best order of events.

Would you suggest :

• Edit the code locally.
• On save upload the file to a test site.
• Test the site on the staging server.
• All being well, commit the changes to the repos. Then run phing.
• Assess output of Phing, updating code as necessary, re-save, re-commit, re-run phing.
• Assuming Phing passes, as I'm running phing on another server, do a svn export and start the deployment process.

The above seems a bit long winded to me. Is it because it looks like I'm trying to merge a test deployment with a live deployment that's confusing me?

Also it would seem a bit backwards to commit, then run Phing, then have to edit and possibly re-commit before trying again.

Hence would it make more sense to :

• Edit the code locally.
• Save, action a test deployment build with Phing.
• Make sure the code has passed all the code checks e.t.c.
• Using Phing make sure code is copied to the staging server.
• Test the site on the staging server.
• All being well, commit the changes to the repos.
• Then live deployment build with Phing.

The problem with the above is, let's say I just wanted to correct the spelling of a word hard-coded into an HTML page, seems overkill?

Finally, how do people set up their servers, do you have one server for the live site, one for the staging, and one to host Phing (and any CI software on)?

Answer 1

The point of tools like Phing is automation. So, to answer this "what stage do you activate it, at what stage in the development cycle is it actioned", I would say you should bring it in as soon as you feel you will gain a benefit from using it.

For example, if you have a process which takes multiple commands to complete, there would be a benefit of using Phing (or even just a shell script) to automate the steps, especially if there's more than one person who needs to do it or it's especially error-prone.

So going with that, you should use phing to make your life easier, not harder. Any task which involves more than one shell command, or always involves typing the same command with lots of hard to remember parameters, is usually something you could/should use phing to automate.

Considering the first list of steps you mention, it is indeed a bit longwinded. Instead, you should use phing earlier, to automate the steps:

• If you have automated tests, use phing to run them
• Commit to source control
• Use phing to deploy the code
• Use phing to do the svn export or any other manual steps

So basically I would do pretty much what you suggested in your second list.

You probably should make phing commands for the separate steps, and make phing commands for running commonly run together commands in one shot (eg. tests and then deploy).

This would allow you to skip phases if you feel it's necessary, such as in the example you gave about changing just some text.

A typical approach to servers is having the live site on its own server, and then having the staging/testing server mirror it as closely as possible. For CI or other utilities, you can usually host them on the staging server, proven they do not interfere with the main application you are developing.