Sam Minnée

Deployment using git push prod

17 June 2010 5:14am. permalink

A good potential workflow for deployment with git: set up a remote repository called 'prod'. Then, do deploy your code you can just push to that.

To set it up, execute these commands on your production environment:

cd /your/web/root
git init
git config receive.denyCurrentBranch ignore
chmod +x .git/hooks/post-receive
echo "cd .." >> .git/hooks/post-receive
echo "env -i git reset --hard HEAD" >> .git/hooks/post-receive
echo "env -i git checkout -f" >> .git/hooks/post-receive

And then execute these commands on your development environment:

git remote add prod sminnee@sam.minnee.co.nz:/var/www/samminnee
git config remote.prod.fetch +master:master
git push prod master:master

One caveat here is that any uncommitted changes on your production environment will be clobbered by the post-update hook. Consider it a work in progress :-).

Deployment build scripts

Post-deployment scripts could potentially be loaded into hooks/post-update. Or, more to the point, hooks/post-update could be configured to run the correct script within the repository.

The way that I chose to do this is with a Makefile. Although Makefiles are a little crude, they are a useful way of aggregating together simple maintenance scripts.

echo "make post-deploy" >> .git/hooks/post-receive

The makefile that I have used for this site is quite simple. It checks sapphire out from subversion, and then runs sapphire's dev/build script to update the database.

post-deploy: 
    if [ -d sapphire ]; then svn update sapphire; else svn checkout http://svn.silverstripe.com/open/modules/sapphire/trunk sapphire; fi
    ./sapphire/sake dev/build

The process for deploying your site is then very simple. Simply call this from your development environment, after checking your new code into the master branch:

git push prod

I've set this up on sam.minnee.co.nz, testing and refining it during the process of writing this article.

The beliefs behind the brands

4 March 2010 3:30am. permalink

(This blog post)[http://gapingvoid.com/2009/06/25/my-next-book-evil-plans/] got me thinking... Brands that people are passionate about do more than sell their product, they embody a bigger belief about humanity.

These examples are perhaps overstated, but you get the point.

• Apple: technology should bring beauty and joy to our lives.
• Ruby on Rails: in writing code you can rebel against the establishment, bring beauty into the world, and in so doing revolutionise the global software industry. In rejecting everything that the previous generation has told us, we are changing the world.

Code snippet: sending a tweet in Sapphire

8 February 2010 1:51am. permalink

Here's a quick post of a tweet() function that can be used to post to Twitter in Sapphire / SilverStripe CMS.

function tweet($username, $password, $tweet) {
    $rs = new RestfulService('http://twitter.com/',-1);
    $rs->basicAuth($username, $password);

    $headers = array('Expect: ');
    $response = $rs->request('statuses/update.xml', 'POST', array(
        'status' => $tweet,
    ), $headers);

    if($response->getStatusCode() != 200) throw new Expection("Tweet couldn't be posted to $username account");
}

Why Markdown?

13 January 2010 10:22pm. permalink

Like many geeks, I have a weakness for shiny new technologies. At the moment, two that I am particularly enamoured with are Git and Markdown. A trap I can fall into with new toys such as this is applying them everywhere, regardless of whether or not they are actually any better than the incumbent tool. Although this can be fun, it's not especially useful.

A better approach is to understand exactly what the biggest benefits of the new tool are. So: why Markdown?

• Like HTML, it's a document markup language that abstracts semantics from presentation. Although it doesn't have the full expressive capability of HTML, it's good enough for my needs, and it's a hell of a lot easier to read in its raw format. This is important, because you need to be able to dig into the raw source form without the use of fancy tools.

I've started by applying Markdown to my blog and to personal documents that I keep stuff jotted down in. This is fairly run of the mill; blogging was what Markdown was designed for.

So, what are some of the stranger ideas that we can apply it do.

To Do List

You can store a to-do list in markdown like this

To do
=====

 * Put out the garbage
 * Do the laundry
 * (Started) Do the laundry

Done
----

 * Cleaned the toilet

The key in using Markdown is to ensure that the source format can be enjoyably edited in a plaintext editor. If you have to actually use the tool in order to make an enjoyable editing experience, then you may was well store the data in XML.

That's not to say the tool is entirely useless - there are always going to be optimisations you can make to the editing experience with a customised tool. Direct editing of the file won't be the only mode of interaction. Rather,

The readability of the data source in its raw form is perhaps an even more important fact. Raw text integrates better with a whole host of tools, not least of which is version control. If the raw format of a document is readable, then so are diffs, blamelists, etc.

Website Update

6 October 2009 9:28pm. permalink

I made myself a CSS stylesheet for a simple markdown viewer that I use for local documents, and I quite liked it. Mostly because I copied the look and feel from elsewhere -- I am, indeed, an awful visual designer. So I thought it might be nice to design myself a new blog / homepage around this.

One fun side-effect of this is that I'm actually able to mock up the template of my blog in Markdown, rather than HTML.

I'm sort of addicted to Markdown at the moment; I'm injecting it into all kinds of inappropriate places in my life. For example, it's become the front-end to my general-purpose word processor, the back-end of which is, of course, TextMate.

Once I mocked up the design of the site in Markdown, I turned it into a proper template, but it was useful for the initial sketch-out.

Managing blog content in git

6 October 2009 9:28pm. permalink

For my new blog, I'm thinking about managing my blog entries using git. Specifically, I will set up a repository that contains a number of markdown files, one for each blog entry. To create new blog entries, I will add markdown files to my local copy, and once I am ready to publish the entry, I can call:

> git push prod

Rather than hard-coding dates into the file content, I will extract them from the git log and filesystem information. This will let me automatically post updates to blog entries simply by committing a change to the file.

It's not clear to me whether I need a separate repository for my site code and my site content. At this stage, I will try a unified approach, and I will only change it if I see the need.

So far, I've set my blog up in this manner, but haven't made any git integration. The dates you see are file modification dates.