Getting going with Heroku and PHP (part 4)

Ok, so this trilogy wasn’t supposed to have a part 4.

In Getting going with Heroku and PHP (part 1)part 2 and part 3, I detailed how I got my website successfully published using Git to push to my “master” branch, have Heroku set to automatically deploy from this branch, and have my Procfile set to point at the “build” folder in my project so everything worked beautifully.

However, there is one drawback to automatically deploying in this way.  You can’t tell from the client when the deploy has finished (or at least I can’t find a way).  This means you need to have your dashboard up to see when it’s complete.  Or just keep refreshing your page until you notice the change, if it’s even a noticeable one.

For this reason, I’ve switched back to before I realised I could point directly to the “build” folder.

My Procfile now looks like this…

web: vendor/bin/heroku-php-apache2

Whilst it takes a few seconds in the command line for the “git subtree” to run and also the deploy, at least I can clearly see the progress and know when it’s finished.

I may flip-flop on this, as there are pros and cons, but for now, I’d rather see that information appear in the command line, rather than go looking for it online in the dashboard.  However, if I write about it, I promise not to call it part 5!

Git aliases

Taking a slight sidebar from my current blog series entitled Getting going with Heroku and PHP (part 1) (and part 2), I’ve discussed that the commands that I am now using to push updates are as follows… gulp git add . git commit -m “A useful commit message” git push git subtree push –prefix build heroku master This…

Making Chrome more beautiful

That’s right, I’m a Chrome-aholic.  I used to use Firefox for everything, but it was really Firebug that we all loved.  I switched to Chrome not long after it came out, and I’ve never looked back. One thing that can be fun to play with are the Chrome Flags.  These are internal feature flags which…