I feel this sort of endeavour is just a poorly researches attempt at reinventing the wheel. Packaging formats such as Debian's .DEB format consist basically of the directory tree structure to be deployed archived with Zip along with a couple of metadata files. It's not rocket science. In contrast, these tricks sound like overcomplicated hacks.
Author here. In case it’s not clear, this article isn't about installing Linux packages; it's about deploying multiple versions of software to development and production environments.
it’s about deploying multiple versions of software to development and production environments.
What do you think a package is used for? I mean, what do you think "delivery" in "continuous delivery" means, and what's it's relationship with the deployment stage?
Again, a cursory search for the topic would stop you from wasting time trying to reinvent the wheel.
Deviam packages support pre and post install scripts. You can also bundle a systemd service with your Deb packages. You can install multiple alternatives of the same package and have Debian switch between them seemlessly. All this is already available by default for over a decade.
Seriously, why the negative tone? If I've offended you, I'm sorry. You might think that I'm wasting time, but there are multiple ways to skin a cat. I prefer not to use DEB packages for deployment, though others might.
If anything goes wrong with the deploy script, such as failing tests, no harm will be done because the script exits upon the first error encountered.
How do you clean up? Once the deploy script is fixed, how do you know what’s been done and what needs redoing?
Have you considered ansible/puppet/chef/salt — environments dedicated to deployment and cleanup, with idempotency to allow for fixing and repeating the deployment, across multiple operating systems and versions?
Cleanup can be as simple as deleting the latest deployment directory, if the script gets that far. The article is about using built-in Linux tools for 'easy' application deployments. One can also use dedicated tools, as you suggested, to further automate the deployment process.
I feel this sort of endeavour is just a poorly researches attempt at reinventing the wheel. Packaging formats such as Debian's .DEB format consist basically of the directory tree structure to be deployed archived with Zip along with a couple of metadata files. It's not rocket science. In contrast, these tricks sound like overcomplicated hacks.
Author here. In case it’s not clear, this article isn't about installing Linux packages; it's about deploying multiple versions of software to development and production environments.
What do you think a package is used for? I mean, what do you think "delivery" in "continuous delivery" means, and what's it's relationship with the deployment stage?
Again, a cursory search for the topic would stop you from wasting time trying to reinvent the wheel.
https://wiki.debian.org/DebianAlternatives
Deviam packages support pre and post install scripts. You can also bundle a systemd service with your Deb packages. You can install multiple alternatives of the same package and have Debian switch between them seemlessly. All this is already available by default for over a decade.
Seriously, why the negative tone? If I've offended you, I'm sorry. You might think that I'm wasting time, but there are multiple ways to skin a cat. I prefer not to use DEB packages for deployment, though others might.
How do you clean up? Once the deploy script is fixed, how do you know what’s been done and what needs redoing?
Have you considered ansible/puppet/chef/salt — environments dedicated to deployment and cleanup, with idempotency to allow for fixing and repeating the deployment, across multiple operating systems and versions?
Cleanup can be as simple as deleting the latest deployment directory, if the script gets that far. The article is about using built-in Linux tools for 'easy' application deployments. One can also use dedicated tools, as you suggested, to further automate the deployment process.