[conspire] Tips for setting up git repositories for web sites?

Wed Feb 25 10:53:17 PST 2015

tl;dr: how do I set up git push on debian?

But first, some of the evolution in my thinking on web site repositories and more about the problem I’m trying to solve:

Some of you don’t know that, while I’m a Mac desktop user, I have a Linux VPS with prgmr.com <http://prgmr.com/> (it used to be a Linux box in the garage, but I ran the numbers and a VPS is a wash long-term cost-wise, plus it doesn’t tax our limited house bandwidth).

I also run my largest (in either space or bandwidth) sites on WP Engine, which is a premium offering involving a careful mix of security, git (via git labs), with a front end involving caching and nginx. WP Engine is a dedicated WordPress hosting site.

I’ve recently learned a lot about git deployment of websites from WP Engine, and I have been re-thinking how I deploy my websites. For the last year-ish, I’ve just dumped the whole directory tree into git, and I push that up to private bitbucket.org <http://bitbucket.org/> repositories as backups.

For years, I’ve simply rsynced, excluding the git directory [1], and that’s worked pretty well. Due to WP Engine’s setup, it doesn’t work there, so I’ve been using the more fiddly and annoying SFTP via Transmit (Mac app).

However, WP Engine’s .gitignore file is a work of art. [2] Essentially, they argue against putting WordPress’s core files in one’s repository [3], because those files are always available.

Historically, I’ve kept my local copy of the website that’s under version control a *complete* copy of the website in question, including any uploads (e.g., [4]), but that’s part of WP Engine’s .gitignore.

Why? Because repositories aren’t backups. I happen to have been using repositories as backups, but they’re not.

In updating sites or moving WordPress sites, *the* most fragile portion of it is not losing all the images in the wp-content/uploads/ directlory. A friend of mine made this mistake last year, and is just now trying to fix it. [5]

So it seems the better technological solution is backing up the non-WordPress-core stuff via a different technological method, e.g., WordPress Backup to Dropbox [6] (which works spectacularly, btw).

For my WP Engine sites, updating a git repository and pushing the changes looks like this:

1. Commit changes to local repo:

	$ git commit -m “my commit message”

2. Push changes to my bitbucket repository:

	$ git push -u origin --all
	Counting objects: 3337, done.
	Delta compression using up to 4 threads.
	Compressing objects: 100% (3249/3249), done.
	Writing objects: 100% (3337/3337), 20.92 MiB | 7 KiB/s, done.
	Total 3337 (delta 346), reused 0 (delta 0)
	To git at bitbucket.org:desamo/desamo.graphics.git
	 * [new branch]      master -> master
	Branch master set up to track remote branch master from origin.

3. Deploy to WP Engine, note the cool commit to a pre-deploy jail:

	$ git push production master
	Counting objects: 3337, done.
	Delta compression using up to 4 threads.
	Compressing objects: 100% (3249/3249), done.
	Writing objects: 100% (3337/3337), 20.96 MiB | 28 KiB/s, done.
	Total 3337 (delta 346), reused 0 (delta 0)
	remote:   git.wpengine.com: validating
	remote:   - warning: changes will be deployed to production application ...
	remote:   - info: validating files in 4c312d1 ...
	remote:   - info: found application servers ...
	remote:   - success: validation complete!
	remote:   git.wpengine.com: deploying
	remote:   - info: preparing application updates ............ done.
	remote:   - info: checking submodules ...... done.
	remote:   - info: ensuring permissions ................................................ done.
	remote:   - info: deploying to production environment .................. done.
	remote:   git.wpengine.com: complete!
	To git at git.wpengine.com:production/desamographics.git
	 * [new branch]      master -> master

*** Now that we’ve taken this rather lengthy stroll on this short pier… ***

So, my current problem is: I’d like to replicate using git push to push to my VPS as well, but I’m uncertain how to set that up on the Debian side. I’ve got quite a few WordPress sites to deploy….

I think it would be far less error prone than my current methodology (which does include a cron rsync push every six hours). It’s harder to accidentally rsync cross directory structures (DAMHIKT) when you use something like git push.

Every time I Google for git or git push and Debian, I get a whole bunch of unrelated articles. Sigh.

Deirdre

[1] Save for a recent oops, documented in this post: http://deirdre.net/elloras-cave-it-infrastructure-statement/ <http://deirdre.net/elloras-cave-it-infrastructure-statement/>
[2] http://cdn.wpengine.com/wp-content/uploads/2013/10/recommended-gitignore-no-wp.txt <http://cdn.wpengine.com/wp-content/uploads/2013/10/recommended-gitignore-no-wp.txt>
[3] http://wpengine.com/git/ <http://wpengine.com/git/>
[4] http://deirdre.net/wp-content/uploads/2015/01/elloras-cave-blog-header.jpg <http://deirdre.net/wp-content/uploads/2015/01/elloras-cave-blog-header.jpg>
[5] http://jennytrout.com/?p=8792 <http://jennytrout.com/?p=8792>
[6] https://wordpress.org/plugins/wordpress-backup-to-dropbox/ <https://wordpress.org/plugins/wordpress-backup-to-dropbox/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20150225/c8e8089f/attachment.html>