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.
this post was submitted on 20 May 2024
25 points (90.3% liked)
Programming
17313 readers
90 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
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.
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.
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.