Why I chose ansible for deployment

With our last project at work, I decided to switch to Ansible as our deployment tool.  So far I am super happy with how it works.  The main points from my (development team centric) point of view are:

• the playbook for detailing how to deploy our application is nice, clean, and straight forward
• the declarative syntax nicely separates the "what" from the "how"
• since the playbook assumes only a fresh OS install with an ssh key, the playbook details every step of the install
• the playbook itself serves as development documentation of what is on the boxes

I follow the general conventions of Twelve-Factor Apps, so I wrote the playbook with the goal of QA, integration testing, and production all being installed using the exact same playbook installing the exact same versions of software.  Just like in a Twelve-Factor App itself, you do this by using variables.

For our local usage, I wrote a simple script that you only have to tell three things:

1. what product you want to install
2. what version of the product you want to install
3. what environment you want to install that product into

The environment is really just the name of an inventory file, so QA and Operations are welcome to create new environments without requiring any changes to the code base or even a new build of the code.

The install script does a few simple steps:

1. auto updates itself
2. downloads the correct version of the playbook, notes, and samples for the product
3. show the user any installation notes for the product and exit, but only if the notes changed
4. runs the playbook for the product with the correct inventory for the environment, passing any extra parameters to the ansible-playbook command

For each new product we create in development, I write a playbook that that product along with a nice set of installation notes that detail what variables are used in the playbook and what purpose they serve.  I also supply a sample inventory that shows a typical install's inventory.  

This means that installing a new app or upgrading an existing app are all the same thing, you run the install tool with the three standard parameters.  If there are new notes for this version, you are shown the notes and get a chance to react to those notes before you run the command again.  If there are no new notes, it just does the install/upgrade.

Due to the power of ansible, that install can be run in check mode to see what will change, or verify that the last install is still correct.  The inventory can contain tags that are used at install time to limit the install to only a few machines to allow for rolling upgrades.

Since the environment is defined by an inventory file, it is super simple to run ad-hoc commands on all the machines for an environment using the ansible command.

StandOut - Floating window applications on Android

Today, I saw an Android library that caught my attention, so I thought I would post a quick note about it.  Hopefully I'll get the time to create some kind of test app using it, but for now, I'll just share the find.

The library is called StandOut and it lets you create floating windows that stay in the foreground while you use other apps.  This would seem to be the most useful on a tablet or other large form factor device, but I guess you could create an app that attaches itself to the side or a corner.  Then that app could pop out when certain kinds of interactions happened.

The app I wrote at work is for drivers that work for couriers and agents to manage the package load/pickup/delivery life cycle.  Some customers have asked for an enhancement to support taking pictures of either documents, the packages, or pickup/delivery location to serve as more evidence of the service details.  One idea that I had was that instead of an icon on the action bar or a menu item, we could hover a small camera icon that jumps the user to activity for picture taking.  I'm still not sure that is a good idea from a UX point of view, so I guess when it comes time to code it we will have to do some hallway usability testing to try out the ideas.

Welcome

At some point or another, most professional programmers attempt a blog.  Most of them do not end up keeping that blog for any reasonable length of time.  In broad sweeping terms, we end up spending most of our creative energy during our working hours on our "job".  And I am no different.  My employer pays for and gets the vast majority of my creative energy.

However, a professional of any stripe should have a portfolio of their work.  And I believe that there is value to be gained by recording our lessons as we learn them.  Not only does that help us personally remember by giving a place to go back and review, but it can also help others learn from our experience.  That old cliché is pretty true: we stand here today upon the shoulders of giants.  Those giants were not a few individuals, rather it is a metaphor, for the combined wisdom of the people before us.

So, welcome to my blog.  I plan on using this as a place to record lessons learned so that I can remember them and so that others can hopefully benefit from them.  In the process, this will also end up serving as part of my portfolio.  I don't know how often I will post here, but I hope to make it a fairly regular thing.  It is my selfish plan to use this as a vehicle for becoming a better writer.  I don't plan on writing a book or anything like that, but creating the written word is a pretty useful skill in and of itself.