I am developing software that is in live use in three installations – lets call them “London”, “Glasgow”, and “Manchester”. There is also the system I develop on (“Developer”) and a system used for final confidence testing before release (“Staging”). Because I have control of Developer and Staging, I can set them both up with exactly the same configuration as London.<\/p>\n
How do I maintain Glasgow and Manchester systems under version control, in an easy and convenient way, using GIT?<\/p>\n
The “obvious” way is to have four branches – “London”, “Manchester”, “Glasgow” and master. Develop in master, and apply those changes to each version in turn using the git rebase command. This will work fine for the first and second changes.<\/p>\n
By the 23rd change it becomes a pain. When one has a string of 30 commits , 6 of which have had to have manual corrections to merges, one gets very fed up of sorting out the same merge errors for every release. Conclusion – process is hard, and I had not got it right yet.<\/p>\n
I put the git repository one level up, in effect creating a number of directories within the directory being maintained by git. One of these was the normal source directory (I am using php). Then I added a directory for each of the three systems, and a directory for the tests. (I use test driven development, and I want the tests under version control as well as the source code).<\/p>\n
Finally I added a “specs” directory and put the specs and notes in there. (Much of the specification goes into a wiki (Wikid Pad – see http:\/\/wikidpad.sourceforge.net\/), which stores the pages in one sub-directory.<\/p>\n
Now I simply added a simple batch file to each of London, Manchester and Glasgow’s sub-directories, to set the main sources directory to reflect that systems configuration, by copying files. The destination files are NOT checked into the repository so I added them to the .gitignore file for convenience. Note that I do control the macros (.bat files) that do the copying.<\/p>\n
I have three three copies of the repository – “Development”, “Staging” and “Reference.” The Reference system is a bare repository (one without a working directory) and is included in the daily backup. Both normal repositories point to the bare one as the origin.<\/p>\n
To do some development work I use the “Development” repo and check out the branch I need (almost always master). When the development is complete and all the tests run, I commit and push the changes to origin.<\/p>\n
To release, I open up GIT on the “Staging” repository, and pull from origin. This pulls all the changes from the bare repository. Then I do a local merge which applies the changes to the staging directories. The “Staging” directory is shared from a Linux machine, and I do the git work on the share.<\/p>\n
But note that the Linux machine also has a web server serving those files. This environment is as near to the production server (appart from the share!) as I can make it.<\/p>\n
A final run of the tests will prove nothing got broken, and then I excercise the system from the staging directories as a final confidence test.<\/p>\n
Releasing is simplicity itself. I use rsync and a small (1 line) script on each production server. The steps are these:.<\/p>\n
An normal “update” release to all 3 sites takes just a few minutes – and there has not been an error in the release process in the last 12 months.<\/p>\n
Advantages:<\/p>\n
Disadvantages:<\/p>\n
The problem: I am developing software that is in live use in three installations – lets call them “London”, “Glasgow”, and “Manchester”. There is also the system I develop on (“Developer”) and a system used for final confidence testing before … Continue reading