Except he packages it on a container.

Which is probably unnecessary if you've got the deployment platform to yourself and can decide that just-run-this-binary is suitable, safe, and manageable. Personally I prefer "just install this .deb" because it wraps up dependency management along with everything else, but that's not been a popular opinion for a long time.

Maybe because creating custom deb packages can be a hair-pulling experience?

But this is our flow too. We have a jenkins job that builds our master branch and uploads deb packages to jfrog. And then another to create a GCP image with these psckages, and a third to actually deploy these images to GCE. Containers are used for the various jenkins jobs, but not on the actual GCE instances.

It depends which tooling layer you're using, really. If you're just saying "bundle up these files and put them on that part of the filesystem" it can be extremely simple. If you're trying to provide the full build-from-source chain... less so. Being able to ignore the Debian Packaging Guidelines is the path to sanity.

In a previous incarnation I wrote https://github.com/regularfry/au to take the grunt-work out of packaging up ruby apps, and pretty much all it does is generate the minimum set of files that `dpkg-deb` needs to spit out an archive.

Debian Developer here.

Reminder: the Debian Packaging Guidelines are meant for official Debian packages.

Making a package with dpkg-deb -b <dir> <packagename> is very easy and gives all the features of APT (dependency tracking, config management, atomic deployment).

Yep. If you're packaging for Debian, the packaging guidelines make sense. If you're packaging something nobody outside your org is ever going to see, you can be a lot more flexible.

Yes, dpkg-deb is a recent discovery. Out of interest, what am I losing by doing it this way rather than if I followed the official guidelines?

The container, if it's `from SCRATCH` is basically just a gzip/zip archive.

https://github.com/opencontainers/image-spec/blob/master/ima...