Whenever you’re dealing with a system that changes over time, at some point you’ll find it useful to go back and see what changes were made 3 weeks ago.
And then you wish you belong to the (small?) group of people who write down every change to a log file, so you can answer this question.
I’m not in this group but have had this need often enough that I’ve tried to automate at least some of the logging.
Twitter to the rescue
Lately, I’ve started using twitter to maintain a timestamped log of the changes we’re making to our production system. It’s very easy to create a dummy twitter account (and make it private if you don’t want to expose all your production info to the public!) for the purpose of tracking these changes.
Since everybody else in the company is already using twitter, it’s very easy, for those who wants this info, to follow this user and get updates whenever something interesting happens.
Posting an update
Twitter has a decent API to access the functionality and posting a new update can be done from the command line, using curl. This makes it easy to post updates from all kinds of places such as build scripts, boot scripts, cron jobs etc.
Since we’re using Gradle to handle all our builds and automation, we can define a Groovy function called tweet, which can be used throughout the scripts:
def tweet(msg) {
ant.exec(executable:"curl") {
arg(line: "--user twitteruser:twitterpassword")
arg(line: "--data-ascii \"status=$msg\"")
arg(line: "--silent")
arg(value: "http://twitter.com/statuses/update.json")
}
}
If you’re doing any manual changes (but of course you don’t, right? Everything is scripted and put under version control 
), you can always manually post an update for the account by using a multi-account aware twitter client.
What to post
So, what can you use this for? Well, you probably shouldn’t post highly sensitive stuff, even if it’s on a private twitter account. But, basically as much useful info as possible. This is when we currently do updates:
- Whenever a new deployment is about to start
- When a deployment is complete (with links to new features, bug solved etc)
- When a new EC2 instance is booting
- Any changes made to the AWS setup
- Etc.
