this post was submitted on 12 Feb 2026
1100 points (97.9% liked)
linuxmemes
29989 readers
2606 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn, no politics, no trolling or ragebaiting.
- Don't come looking for advice, this is not the right community.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
5. π¬π§ Language/ΡΠ·ΡΠΊ/Sprache
- This is primarily an English-speaking community. π¬π§π¦πΊπΊπΈ
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed. Β
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I get CLI users, sometimes using the cli is faster and more efficient.
However I have had frequent discussions with people (all of them also avid CLI users) that set up infrastructure as code. I prefer the super understandable Gui of a tool like octopus deploy over hundreds of yaml files whose content can only be understood by doing a year long deep dive any day.
They always use the same two arguments: Infrastructure as code allows you to rebuild your entire software deployment from scratch, and the code can be versioned, thereby providing an audit trail for deployments.
In decades of software development I have exactly had to redeploy an entire network from scratch 0 times. If you're in that stage the cause is most likely hardware and re-provisioning that will probably take the bulk of your time.
About the versioning: I'm not arguing against storing deployments as yaml files, but writing them by hand is insanely inefficient. There should be a nice GUI that generates and writes these yaml files, so you don't have to know every option an value and every validation rule by heart.
Also, I am relatively certain that a tool like octopus deploy also has auditing of who deployed what software in which location.
To me the power of IaC is less in "I can stand this whole thing back up a single deploy" and more "The entire history of every configuration decision and change I've ever made is right here, not buried 4 submenus deep in a "new enhanced ui".
When we're being audited for security/privacy/legal compliance, I have one source of truth to look at, and when it gets changed, those changes get peer reviewed just like any other code change, and git history is a great audit trail if you use decent commit messages.
Also, knowledge transfer and onbording is way easier too, here's all our infrastructure, here's the rules surrounding how it gets updated, yes you will be fired if you break them. Here's the docs regarding how to write this code, and here's some handy formatting and validation scripts to help you along the way.
Doing it by hand in the console is fine if you have full confidence in your ability to hand over the project to another human on your way out the door, but when it comes to that one hacky workaround you had to implement with no documentation due to the limitations of your in-house apps, you're probably forcing the next guy to rediscover why you did it that way by breaking it half a dozen times on the next deploy after your departure, rather than just noticing the inconsistency in the IaC, then looking into the git blame and mumbling "heh, that's dumb".