Package Management - shipping code natively

When I first moved into the Bay Area, Rails was still all the rage. People were so enthralled with the magic of standing up a web application on their laptops solo, that everything else was an afterthought. It was somebody else’s problem. That somebody else was me, and I look back on that time in frustration at the lack of thought that went into shipping code. I still remember the horrors of Capistrano; and all the following attempts at re-inventing the wheel on production pushes; ignoring decades of Unix conventions. Most of all, I remember all the things that we did instead of using the native package management tools that were built into every single node running our services. Omnibus was clunky, but a huge step in the right direction. Unless you’re company is the next Facebook, chances are you will never devote enough resources into shipping code to ever reach the amount of speed, flexibility, and resiliency tools like apt, yum or pacman provide. The onus is not on them to demonstrate this fact, they already have or we wouldn’t be using their operating system distributions to host applications. I don’t look back on those times fondly, and I’m greatful tools like FPM exist today to bridge that gap between native integration, and custom deployment. What about roll back you ask?

/etc/apt/preferences

Package: inhouse_custom_application
Pin: release a=stable
Pin-Priority: 1200

Then your Fabric instructions are reduced to a one liner:

from fabric.api import local

    def push():
        local("apt-get update; DEBIAN_FRONTEND=noninteractive apt-get -y upgrade")

Security patches stay up to date, rollbacks are an S3 bucket revision away, and code gets deployed immediately as a pseudo push operation.

Golang, and one day maybe the entire JVM, ship the runtime and code compiled into a single executable, reducing the deployment complexity during the build operation. We’ve come a long way in less than a decade.