Distribute Native Packages
|date:||Aug 28, 2014
As a system administrator I deploy a lot of code. As web developer I
write a lot of code. Yet these two parts of me are always at odds.
When working on web applications the system administrator in me says
“Just ship it!”
While the web developer screams “It’s not perfect yet!”
And when the code finally gets deployed, things inevitably fall over in
My years of experience being both a developer and system administrator
have taught me that the best way to distribute applications is by using
Turning unmanagable deployments...
into well oiled machines.
Native packages provide three major benefits over other deployment
The first benefit native package provide is security. This is an
optional benefit, as signing packages does not preclude them from being
Every time I have to install RVM, I die a little
The RVM website provides a single method of installation:
$ \curl -sSL https://get.rvm.io | bash -s stable
This is horribly insecure, dangerous, and the definition of remote code
Though RVM encourages installation over HTTPS, SSL is not enough
security for software distribution, because does not verify the
integrity of the content.
By using signed native packages instead, you can verify two things:
- The package contents haven’t changed since it was created.
- The package can only have come from the owner of the signing key.
This is because servers installing the package will already contain the
author’s public key.
Modularity is the second benefit native packages provide.
Native package create modularity by providing a clear distinction
between the build and deployment steps of a web application. This leads
to a highly scalable and continuously deployable application, which falls
in line with The Twelve-Factor App definition.
Applications that don’t have a clear distinction between these processes
tend to have deployments that organically grow into complex
This complexity can be seen clearly around the upgrade and rollback
processes. Modularity comes from taking these processes and sectioning
them into before/after install and remove scripts. Instead of being ran
by an external process that requires elevated privileges to a production
server, these scripts - which are packaged with the application - execute
during upgrades (installing a new version) and rollbacks (downgrading
The final benefit native packages provide, is maintainability.
Instead of maintaining complex execution definitions or a plethora of
SCM resources in configuration management, system administrators have
only to write a few simple resources: install application, upload
configurations, restart services.
This leaves them with more time to fix important issues (like putting
out fires), and keeps them from having to spend multiple hours deploying
Where it All Breaks Down
Even with all these benefits, native packages are not a silver bullet.
A new (but simple) piece of infrastructure will need to be setup to host
package. If binaries are being signed, public keys will need to be
shipped with server images, and signing will need to be integrated into
the build processes. Migrating existing deployment architecture will
take time, along with the creation of packaging scripts.
And finally, multiple packages may need to be created for any server
that runs multiple versions of an application.