After having researched Git, and deciding on what Git host to use (between GitHub or BitBucket), since BitBucket can connect very easily with our team’s issue tracking platform, we went with BitBucket. It pretty much works in the same fashion as GitHub, so there’s not much to explain beyond your normal Git hosting solution, but the ability to track issues right from the Git command line was a huge plus for me. As long as I know the issue ticket ID, I can use that in a commit, as well track the time it took to work on the issue, and set the ticket’s status as well. This is not only good practice, but also a huge time saver in the development process.
For now, Strategic Communications will be storing it’s code bases for the Image Archive, the WordPress News site instance, and the UC Irvine WordPress Theme in BitBucket as individual repositories. Commits to these repositories occur 3 to 4 times a day, and tagged versions of the code will correspond to new phased releases of the sites or code base.
All version hosting set aside, the primary reason I got Git (heh!), was to make site deployment a smooth transition with as little steps as possible. Although I am pretty disciplined with site maintenance, using loosely connected FTP procedures, and tools like rsync, there’s simply way too many vectors that could lead to something being permanently lost, or overwritten, and therefore compromising the integrity of the codebase, and potentially bringing down whole websites.
There’s a really good tutorial here, that explains how to set up a remote repository, that will right all code to a web root, on the git push hook. The example outlines a simple implementation, but I so I used it, and then made an extra hook to be used at a later stage to an additional remote web root. The idea is that when the master branch is checked over for clean and well-tested code, I can deploy the code to both our development and production servers. I’ve created two separate origins based off the master branch in a particular Git repository. There’s one for staging, which is ported to our development server, and another for production, which is ported to the live server. The local git instance is hooked to the development server’s git instance, and the development server’s instance is hooked to the live site, upon push from the local instance. I especially like the facet of this deployment tool that will update and remove assets that exist only in the repository, and will leave files on the production and development servers, that have not been contributed to the repository as is.
This is a welcomed solution to my prior process of updating custom sites and code. No more forgetting to upload necessary files, or having the development code base out of sync with the production one.