Automate everything! – The power of puPHPet

As you readers probably know, I can’t stand XAMPP and MAMP, being two steaming piles of crap, and have long advocated that you set up VirtualBox & Vagrant, then head over to, fill in the forms to configure your VM,  generate the config.yaml, and then unzip it and run ‘vagrant up’ to install it. Brilliant so far.

Yesterday I had a total downer of a day, trying to run an old legacy PHP 5.3 app. PuPHPet doesn’t have the EOL PHP 5.3, so at first I settled as a one off for MAMP, but it was slow and horrible.

Then I thought, wait! If I don’t configure Apache or PHP in puphpet, I could get a box up and install 5.3 myself. That’s when I discovered the awesomeness of the puphpet/files folder.

The only thing I used in there was the ssh keys. But there are empty folders waiting for .sh files (shell scripts) to be dropped in.

So for this box, I created exec-once/ which contained the following:

yum -y install httpd php
yum -y install php-mysql php-devel php-gd php-pecl-memcache php-pspell php-snmp php-xmlrpc php-xml

Then upon running vagrant provision, it not only looked for changes in config.yaml, but it checks for changes in these files too!

I then made, and, which look like these:

echo "
Adding vhosts to /etc/httpd/conf/httpd.conf
echo "
<VirtualHost *:80>

   DocumentRoot /var/www/fife/web
   ServerName fife
   ErrorLog /var/www/fife/log/error.log

   <Directory "/var/www/fife">
      Options -Indexes +FollowSymLinks
      Order allow,deny
      Allow from all
      AllowOverride All

" >> /etc/httpd/conf/httpd.conf

And …

mysql -u root --password=123 --database=fortdev < /var/www/fife/data/sql_scripts/symf_fortdev.sql

I take it by now you get the idea! So now you can totally destroy your VM, and put any customisations in these shell scripts, so your full setup can be back up in 5 minutes flat with a vagrant up and vagrant provision!!!

You can then also start thinking about using puPHPet for deploying your setup to your production server 🙂 There’s a vagrant plugin called Vagrant Managed Servers, which will take care of that for you. . I haven’t looked at it yet, but of course you can expect a blog post on it here when I figure it all out!!


Using Git Push to Deploy your websites

If you’re STILL using some sort of FTP to deploy your website, you are falling behind! FTP sucks for a variety of reasons. My Favourite FTP client? I dobn’t have one! Dreamweavers file manager/ftp client was quite good, but thats the only thing I used dreamweaver for, the Sync site button. And even that left horrible _notes folders lying around everywhere. The one thing I liked was the cloak file ability, so only certain files/folders were uploaded. But Dreamweaver is sh*t. And will forget what it had previously done. So using Filezilla and manually uploading the things you wanted was your only option. And the setting ftp rules thing was more hassle than its worth. So it’s time to move on.

If your project isn’t big enough to be requiring Continuous Integration software from the likes of Jenkins, then a Git ‘push to deploy’ setup might be exactly what you are looking for. Make changes, commit, and push, which sets off the deployment process using a git hook, which is nothing more fancy than a bash script. So lets get started! I assume you have a live server with SSH access, and a development server which you will be working on.

SSH into your live server as root (or sudo su once logged in). We will be creating a user group for every user that will be pushing should be added to, and creating a folder for keeping your repositories in.

groupadd geeks
usermod -a -G geeks myusername
usermod -a -G geeks otherusernameetc
mkdir /var/git
chmod 775 /var/git
chgrp geeks /var/git

Now exit from being root and be logged in as whatever your normal ssh username is. We will be initialising a Git repository in the sites document root.

cd /home/myusername/www
git init
git add .
git commit -a

Now we will create a bare repository which will be the origin. This is what our dev copies will push to, which will set off a hook deploying to the web doc root. Once we create it, we’ll push whatever is in the sites doc folder already to it.

cd /var/git
mkdir yourprojectname.git
cd yourprojectname.git
git init --bare
cd /home/myusername/www/
git push /var/git/yourproject.git master

Now we add the live’s ‘origin’ repository as a remote for the live. Edit /home/myusername/www/.git/config, add add the following:

[remote "origin"]
    url = /var/git/yourprojectname.git 
    fetch = +refs/heads/*:refs/remotes/origin/*

Great. Now all that’s required is to set up what we call a ‘Git Hook’, a bash script which will trigger when we push to the master repository.
Edit /var/git/myproject.git/hooks/post-update :

echo "*********************************"
echo "*** Deploying Website LIVE ***"
echo "*********************************"
cd /home/myusername/www || exit
unset GIT_DIR
git pull origin master
git submodule init
git submodule update
exec git update-server-info

Save the file, and edit its permissions to make it an executable:

chmod +x /var/git/yourprojectname.git/hooks/post-update

You’re all set! The last stage is to clone your repository to your testing server, so, on your testing server:

cd ~/Sites
git clone myusername@myliveserverIP:/var/git/yourprojectname.git yourprojectname

And Bob is indeed your uncle! Test it out! If you have an index page (be it PHP or HTML, whatever) :

nano index.php
    <h1>My Groovy new Website</h1>
git add .
git commit -a
git push origin master

Now go check your live site! You should see your changes reflected on your production server 🙂 Have fun people!