Thanks to Danilo, Ram for their insights on this topic.
In a section called Principles and Practices of Build and Deployment Scripting, the CD book suggests to Use Your Operating System’s Packaging Tools
“Deploying a bunch of files that need to be distributed across the filesystem is very inefficient and makes maintenance—in the form of upgrades, rollbacks, and uninstalls—extremely painful. This is why packaging systems were invented.”
We concur. This is a good example of cross-pollination of good ideas between development and operations. Software development teams are increasingly packaging their applications using application-specific (maven, gem, wheel, npm, cpan…) or system (rpm, deb, nuget, chocolatey...) packaging tools. Doing so has several advantages:
Distribution via standardized repository layouts, metadata and protocol.
Transactional install/upgrade/uninstall via package managers.
Managing configuration files: OS packages know how to manage files that are expected to change after installation so you don't lose your changes when you uninstall or override when you upgrade. e.g. rpm’s %config macro.
File verification: Packages have built-in checksums, which can be used for verification before a package is extracted and installed.
Traceability - what repository did a package come from? (e.g. deb)
Infrastructure automation tools like Chef, Puppet and Ansible have good support for popular package management systems. Traditionally used for provisioning servers, and environments, these tools are increasingly being used for application provisioning - more on this point in a follow-up post.
There you go - eleven good reasons to start creating packages for your components and applications and deploying from packages rather than from a tag, branch or binary.
Package Material support in Go 13.3
We are happy to announce that the next release of Go (13.3) will support packages as material for pipelines. Watch this space for the official release announcement and feature details.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.