January 12, 2012

Bash'ing your git deployment

Chuck Norris deploys after every commit. Smart men deploy after every successful build on their Continuous Integration server. Educated men, deploy code directly from their distributed version control systems. I, being neither, had to write my deployment script in bash.

We're using git and while doing so I wanted us to:
  • deploy from working copy, but...
  • make sure that you can deploy only if you committed everything
  • make sure that you can deploy only if you pushed everything upstream
  • tag the deployed hash
  • display changelog (all the commits between two last tags)

Here are some BASH procedures I wrote on the way, if you need them:

make sure that you can deploy only if you committed everything
verifyEverythingIsCommited() {
    gitCommitStatus=$(git status --porcelain)
    if [ "$gitCommitStatus" != "" ]; then
        echo "You have uncommited files."
        echo "Your git status:"
        echo $gitCommitStatus
        echo "Sorry. Rules are rules. Aborting!"
        exit 1
    fi
}

make sure that you can deploy only if you pushed everything upstream
verifyEverythingIsPushedToOrigin() {
    gitPushStatus=$(git cherry -v)
    if [ "$gitPushStatus" != "" ]; then
        echo "You have local commits that were NOT pushed."
        echo "Your 'git cherry -v' status:"
        echo $gitPushStatus
        echo "Sorry. Rules are rules. Aborting!"
        exit 1
    fi
}

tag the deployed hash

Notice: my script takes first parameter as the name of the server to deploy to (this is $1 passed to this procedure). Also notice, that 'git push' without the '--tags' does not push your tags.
tagLastCommit() {
    d=$(date '+%y-%m-%d_%H-%M-%S')
    git tag "$1_$d"
    git push --tags
}

This creates nice looking tags like these:
preprod_12-01-11_15-16-24
prod_12-01-12_10-51-33
test_12-01-11_15-11-10
test_12-01-11_15-53-42

display changelog (all the commits between two last tags)
printChangelog() {
    echo "This is changelog since last deploy. Send it to the client."
    twoLastHashesInOneLine=$(git show-ref --tags -s | tail -n 2 | tr "\\n" "-");
    twoLastHashesInOneLineWithThreeDots=${twoLastHashesInOneLine/-/...};
    twoLastHashesInOneLineWithThreeDotsNoMinusAtTheEnd=$(echo $twoLastHashesInOneLineWithThreeDots | sed 's/-$//');
    git log --pretty=oneline --no-merges --abbrev-commit  $twoLastHashesInOneLineWithThreeDotsNoMinusAtTheEnd
}

The last command gives you a nice log like this:
e755c63 deploy: fix for showing changelog from two first tags instead of two last ones
926eb02 pringing changelog between last two tags on deployment
34478b2 added git tagging to deploy


3 comments:

  1. Great post, thanks for the tips. And now just push that to CI to do that after every green build :-) and call yourself an educated man :-)

    I believe Chuck Norris is actually editing files on production directly and needs no version control.

    ReplyDelete
  2. Truth to be told, I know one Saper kind of guy. He's an Oracle SQL dev, he connects to the production database in the morning and disconnects in the evening. He doesn't use version control. He doesn't write tests. He doesn't run his PL/SQL procedures on a test server. He does not make mistakes. If he did, one third of Poland wouldn't have mobile connection. Even better: one third of this country wouldn't have their mobile data plans anymore. If one day, you turn your TV on and there is not Teleranek, tanks are raging the streets, and some general talks about war, he is the one to blame. His name is Krzych, though some call him YHWH, the Omnipotent, or the Higher Good. He's not to be messed with.
    Chuck Norris signs his paychecks.

    ReplyDelete
  3. In Soviet Russia, production deploys you. :)

    ReplyDelete