Build Application Packages with FPM

Tags: devops

FPM changed the way I think about packaging. I wrote so many lines of custom deployment code just to skip packaging our in-house application in the past, and it was completely justifiable given my previous experience with packaging tools

I mentioned last time that we’re living in the future. Things have changed for the better.

We now use Puppet for provisioning and configuration management, and that extends to our in-house applications running on those servers. We also have internal package repositories. Packaging pain kept us from fully using this infrastructure for our in-house applications, but FPM changes that.

Say we have a custom application to package. This isn’t an official release, it’s just a build triggered by the latest commit, and we have it laid out on disk just like it should be deployed. Easy:

timestamp=`date +%Y%m%d%H%M`
version=`git rev-parse --short HEAD`
    
fpm -s dir -t rpm -p ~/ourawesomeappliation-0.9.${timestamp}git${version}.rpm \
    --name ourawesomeapplication -v 0.9.${timestamp}git${version} \
    --prefix /the/place/to/deploy/it --exclude '*/.git/*' --verbose \
    --debug .

The time stamp ensures that the system can compare versions correctly since git version hashes aren’t alphabetically ordered.

And for the Mercurial projects out there:

timestamp=`date +%Y%m%d%H%M`
version=`hg log . | head -1 | sed -e 's/.* //' -e 's/:.*//'`
   
fpm -s dir -t rpm -p ~/ourawesomeappliation-0.9.${timestamp}hg${version}.rpm \
    --name ourawesomeapplication -v 0.9.${timestamp}git${version} \
    --prefix /the/place/to/deploy/it --exclude '*/.hg/*' --verbose \
    --debug .

Note that we’re creating RPM packages above. Also note that the -t argument defines the OUTPUT_TYPE or target. Swap in deb for rpm to get a Debian themed party started. Solaris packages are an option, too. That’s right, some people still deploy more than just Oracle products on Solaris machines.