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

You May Also Like

Context menu or Action buttons ?

Recently I was drawn into one of those UI "religious" disputes that has no easy answers and usually both sides are right. One of our web developers was trying out new web tech (with pretty rich widget library) and started to question himself about some basic usability decisions. The low level problem in this case is usually brought to "which widget should I use ?". I'm not fond of bringing the usability problems to questions: Should I use Tabs over Menu ? Or should I use Context menu instead of buttons panel ? But sometimes if time is crucial factor and other usability levels are by default not addressed at all - better developer that asks those basic questions than developer that do not question himself at all.