In Part 1 of this article, we discussed setting up your git repository server. This post will explain how to use that server to deploy primary and development versions of your site.
We’re going to start on a non-git part of the setup: creating your development subdomain: Whenever you’re working on a new subdomain the first thing to do is actually create the A-Record with your hosting provider because these records can take a while to propagate around DNS. If you’re not familiar with A-Records they’re basically just a way for DNS to know where to send requests for any subdomains of your site; here’s Linode’s information on them other hosting providers will obviously have different settings but you’re basically looking to modify your DNS settings. For my development purposes, I created a ‘dev’ subdomain with the same IP as my main server and left TTL as Default. (I also created another one for this ‘blog’ subdomain, but that’s obviously not part of this guide.)
While those new DNS records are being spread around the globe you’ll want to create separate Apache virtual hosts for your dev subdomain (again some Linode documentation). Your new Dev host should look something like this:
# Admin email, Server Name (domain name), and any aliases
# Index file and Document Root (where the public files are located)
DirectoryIndex index.html index.php
# Log file locations
CustomLog ~<yourUsername>/public/<yourURL>/log/access.dev.log combined
Once you’re done with that remember to restart the Apache2 service so it sees your new config files. Assuming your DNS updates have propagated, you should now be able to see something when you point your browser at dev.<yourURL>. If you don’t, work on the steps below and check again in a few hours.
At this point I’m going to assume you already have some sort of working website, no matter how basic, that you want to keep running as is while you tinker with your dev version on the subdomain. If you don’t already have a site just create a basic index.html page and put it up at your main (non-subdomained) URL to get yourself started.
Now you need to use the gitolite-admin control repo you set up in the first part of this guide to create a new repository for your site. I just called mine ‘site’, but a more descriptive name is probably better. Change your working directory on your Linux server to the DocumentRoot path to your dev site which you set in your Apache config files earlier, and run the following command:
git clone git@<yourGitServer>:site
This should clone the empty repository to your new development subdomain. Now copy all the files from your production site’s DocumentRoot path to your new development site DocumentRoot, add them all to git, commit them, tag your commit, and push them back to the repository.
cp -r <prductionDocumentRoot>/* <prductionDocumentRoot>/.* .
git add .
git commit -a -m "Initial Commit"
git tag "v1.0"
If everything went right, the repo that you created in part 1 should now contain the entire contents of your site. To test pulling it to your production site, create a new folder in the same one as the DocumentRoot of this site, cd into it, and try to clone your site’s repo with the command:
git clone git@<yourGitServer>:site
You should end up with a second copy of all the files in your site with the addition of the .git folder which has the file history and your repo information, so go ahead and swap this new git-ified version of your site with the main version:
mv <siteFolder> <siteFolder>.non-git-version
mv <siteFolder>.gitversion <siteFolder>
If everything still works when you try your site, you’re in great shape. Hopefully your subdomain is working as an identical copy of your site now as well. If it still isn’t run the following command on your local machine to check what your DNS server is returning:
Both commands should return the same IP address, if not, something is wrong with your config or your DNS servers haven’t updated yet.
I’d suggest a few small .htaccess file tweaks at this point. First, make sure your .git files can’t be seen by people visiting your site (you should probably apply this to both your dev and primary site’s .htaccess files, or change one and push/pull it to the other with git for practice). Second, on your dev site, you’ll want to limit access by IP address to just your own IPs so people can’t see your less-secure development code. Finally, tell git to ignore your .htaccess files in the future so that you dev version with IP restrictions doesn’t get pushed to your main site.
Wow, that took a while. Stay tuned for Part 3 where I finally describe how to set up Coda 2 with this mess.
Update: still no Part 3, but Part 2.5 is up.
Liked this post? Follow this blog to get more.