Friday, 9 March 2012

GIT - My Design Choices (Windows, Linux, Remote and a Live Website)

Part1 - The explanation

So, for a while I was the only developer writing code for our Moodle installation (PHP, MYSQL, AJAX, CSS etc) which, when testing and putting live, meant I could just about get away with FTP access to the servers. When two new developers joined my team this process couldnt continue so I decided to install and use GIT, the content versioning system. It gave me the chance to control what went live when, and in what state, as well as allowing us all to work on the same code without having to keep track of what we had changed.

This blog post isnt about why I went with GIT, but about how I set it up and the way I set it up.The steps I took came from many different blogs, internet posts and books:
The problem I had with many of the above is that they either assume your GIT is just on one server or machine, or that when you are using a remote repository, that you are using GIT Hub. My setup is the following:
  • Centos 5.4 Live server (This has Moodle (a website) on it).
  • Centos 5.4 Dev server (A copy of Live that we use for testing)
  • Developer machines using Windows 7.
  • Not being attached to any other 3rd party GIT repository. 
Before I begin: I am not a GIT expert and so there may well be better ways of doing some of the stuff I did. I would also say that I only did this a few weeks ago and so havent gotten far down the line of versions and histories to find any problems with my setup. 
Designing My GIT
Ok, so what I wanted to be able to do was code on my local machine, test on a development machine and then push the code to a live server. My local machine is a Windows 7 machine with an XAMPP server where Moodle (the php files) are sat in c:/xampp/html/moodle and can be accessed via http://localhost/moodle. The dev server is Centos 5.5 and moodle is in /var/www/html. The Live server is a copy of dev (the difference is the web address and permisions). 

I decided to have a git repository on my local machine, one on the dev server and then two on the live server. This would give the following: (I explain why I have two GIT repos on Live below)

  1. Are the hooks that keep the prime and hub in sync. (see below). These are called automatically and never by us.
  2. Dev is cloned from the HUB and then when DEV needs to be pushed Live, it is pushed to HUB.
  3. Localhost is a clone of DEV. Code is changed on localhost. When it is ready to be tested on DEV then it is pushed to DEV.  
Two GITS on LIVE:
So, why two gits on LIVE? Well, I wanted to be able to do a push from DEV when we are happy with the code. This will then automatically update what is executed in the browser on LIVE. I initially thought about just having one GIT repo on LIVE and simply pushing to it, but the problem is that its not a good idea to PUSH to a live website see http://git.661346.n2.nabble.com/Managing-websites-with-git-td1595624.html where they debate the reasons. (Basically with one push to a live website it will not update the working copy, (the code that will get executed in the browser) and a script would need to be written to then checkout the branch, but its far too easy to mess things up with Index's, Heads, Branches and code). 

So I have two repos both of which are mirroring each other and both only have one branch, the master. The HUB repo is a bare repository, in that it has no working directory (you cant see the files that are checked out if you browse to the folder) and this is the repo that we will connect to from DEV. The PRIME repo is a repo that has a working directory (namely the code that is checked out is the code that the live Moodle website will run and can be viewed when you browse to the folder). 

To keep the two repos in sync you create two rules, called hooks
  • Post Update hook on HUB
  • Post Commit hook on PRIME 
The Post Update hook on HUB is executed after a push is sent to it (a push from dev in our case). Our hook will change to the PRIME location and do a pull from HUB. This will checkout the branch and updatde the working copy.

The Post Commit hook on PRIME is executed after code is commited into the PRIME GIT repo. (Imagine FTPing code up and wanting to add it to the repo). If this is done then HUB and PRIME will be out of date and so the post commit hook will solve this. It does a push to the HUB and thus ensuring that the repos are in snyc (as hub doesnt contain a working copy it doesnt matter that it wont update a working copy.)

If you follow the above through you will also notice that it will call the post update hook on HUB after doing the post commit hook on PRIME.

The GIT Setup Steps
  1. Install Git on Live
  2. Create a repo over the live code (add and check it all in) (PRIME)
  3. Create a bare repo in /git  (HUB
  4. Add PRIME as a remote repo on HUB and clone it
  5. Add post push and post comit rules to PRIME and HUB.
  6. Install GIT on DEV
  7. Create a repo on DEV and add LIVE as a remote repo on DEV
  8. Clone LIVE
  9. Install GIT, Tortoise GIT, PUTTY and associated programs on Windows. 
  10. Add DEV as a remote repo on windows
  11. Clone dev
  12. Create additional branches on DEV and play around.  
Step 2 is how I installed everything.

No comments:

Post a Comment