Yes more you don’t need
My deployment platform is a shell script
51–60 of 141 posts
Re: My deployment platform is a shell script
#52Earlier quoted context omitted.
I agree with most of this, my biggest issue is how hard it is for me to recall any moderately complex shell syntax (or the slightly different Makefile syntax). LLMs largely solve that for me.
The bash man page is my bible. It's dense and long but it always has the answers, you just gotta know where to look.
When people mention `bash` it's immediately a code smell. In order to write portable shell scripts, it must be only POSIX `sh`. If the need ever arises for a more complex data structure, typically I jump into AWK since it's also POSIX compliant.
Here's a note from the Ubuntu recommendation: https://wiki.ubuntu.com/DashAsBinSh
Re: My deployment platform is a shell script
#53I use similar things for bigger (multi-server) deploys too. It's light and it just works and works for decades without changes/updates. People say it's brittle; I have a proof of n>0 that this is not the case compared to many other solutions, this post making that point too. Sh/bash/perl(8) have been around forever, they don't break after update etc. I sadly don't recommend it for my day job, simply because of liabil…
[flagged]
If we’re using the script in the post as an example, that’s hardly a “mess” of shell scripts. I’d rather maintain that than almost any other build system I’ve ever seen.
Re: My deployment platform is a shell script
#54I use similar things for bigger (multi-server) deploys too. It's light and it just works and works for decades without changes/updates. People say it's brittle; I have a proof of n>0 that this is not the case compared to many other solutions, this post making that point too. Sh/bash/perl(8) have been around forever, they don't break after update etc. I sadly don't recommend it for my day job, simply because of liabil…
[flagged]
It’s funny because in my many years of development I don’t think I’ve ever encounter a “mess of shell scripts” that was difficult to maintain. They were clear, did their job and if they needed to be replaced it was usually simple and straightforward.
Can’t say the same for whenever the new abstraction of the day comes along. In my experience what the OP is saying is exactly my experience. The abstractions get picked not because they are best but because they reduce liability.
Re: My deployment platform is a shell script
#55The use of ls in this way is not good form: cd /root for project in $(ls go-cicd); I think a better expression would be: for project in ./* do [ -d "$project" ] || continue ...
Why is that not good form?
Re: My deployment platform is a shell script
#56I use similar things for bigger (multi-server) deploys too. It's light and it just works and works for decades without changes/updates. People say it's brittle; I have a proof of n>0 that this is not the case compared to many other solutions, this post making that point too. Sh/bash/perl(8) have been around forever, they don't break after update etc. I sadly don't recommend it for my day job, simply because of liabil…
[flagged]
I don’t think ‘axe to grind’ was what I took away from the comment. And if it’s a ‘mess of shell scripts’, I can’t imagine any of the mentioned solutions to this being better.
I think we lose focus of the fact that we invented a whole new career track- devops. And it basically is about getting code from developers’ machine or environments to production. And we’re still terrible at it.
Perhaps that should be a signal that we’re doing it wrong…
Re: My deployment platform is a shell script
#57Earlier quoted context omitted.
[flagged]
It’s funny because in my many years of development I don’t think I’ve ever encounter a “mess of shell scripts” that was difficult to maintain. They were clear, did their job and if they needed to be replaced it was usually simple and straightforward. Can’t say the same for whenever the new abstraction of the day comes along. In my experience what the OP is saying is exactly my experience. The abstractions get picked…
Hello. I have found the mess of shell scripts. Please don't do this.
I was able to deal with the weird skaffold mess by getting rid of it, and replacing it with argocd. I was able to get rid of jenkins by migrating to github actions. I have yet to replace the magic servers with magic bash scripts. They take just enough effort that i can't spend the time.
Use a tool i can google. If your bash script is really this straight forward and takes you from standard A to standard B, and it's in version control then bash is AMAZING. Please don't shove a rondom script that does a random thing on a random server.
Re: My deployment platform is a shell script
#58I can't speak to the validity for the author's use case as I'm not a golang dev, but in spirit I do like the idea. I think this trend back to simplicity (monoliths, sqlite, bash scripts) makes it good timing to be posting and learning things like this. Especially as more and more new, easy/low config tools come out like Caddy, this gets simpler over time. I have a testbed boilerplate project for Laravel in which serv…
I’d like to think that there is in fact a trend towards simplicity. But with AI and AI written code, I unfortunately think we may be heading to having even more opaque code.
Re: My deployment platform is a shell script
#59Or, you could use NixOS and just declare your systems in some text files, git commit; git push.
You build script becomes:
while true; do
git pull
nixos-rebuild switch
sleep x
done
I've completely removed Ansible as a result and no more python version mismatches, no more hunting endless task yaml syntax, no more "my god ansible is slow" deplyments.
Re: My deployment platform is a shell script
#60The use of ls in this way is not good form: cd /root for project in $(ls go-cicd); I think a better expression would be: for project in ./* do [ -d "$project" ] || continue ...
Why is that not good form?
It omits some characters from its output. It also mangles some others through octal escape codes or other such stuff. Depending on flags it will also not handle filenames with spaces or newlines properly. ls output is meant for human consumption, not parsing.