Last Updated: February 25, 2016

Release practices for applications

I am assuming here that you are aware of version control, continuous integration and do releases on a UNIX based enviroment. These are some of the best practices we follow when we release new versions of our app.

Git tag every release with the date-personName or a release name. This way it is easy to revert to a version for bug fixes.
Always save the last 3 build artifacts, either on your CI box or on production. In case you need to revert the production version, it is always faster to deploy the built artifact than to build it again.
Back up your databases. And don't just back them up locally. We auto backup our databases to S3 every 12 hours.
If you are continuously deploying your app or have release mirrors, you need to be able to figure out what version of the app is currently running on production. Create a version file which uses git log command which is accessible from the web. I have seen SHA's as HTML comments as well. Here is a screenshot of our version page
Always inform your customers/stakeholders about downtime if any. Create a customers mailing list for this purpose. Create a default "Under Maintenance" page on the application root during a release.

Automate as much as possible. Here is a fun script that tells you whether a git repo has been updated or not. Use the script to auto update simple websites, web-apps and basically anything else using the shell.

#!/bin/sh
remote=$1
o=.git/remote_cache.$remote
n=$o.new$$
git ls-remote $remote &gt;$n
if [ -f $o ]
then
        if diff $o $n &gt;/dev/null
        then
                echo "No Changes"
        else
                mv $n $o
                echo "Updated"
        fi
else
        mv $n $o
        echo "New remote remembered..."
fi

This script returns "Updated" if a git repo has changed since the last time this script was executed. Use this for anything from backing up your database, triggering a CI build, sending an email or auto deploying your application.