You can also use webhooks to deploy with each GitHub push. The advantage over GitHub actions is you don’t have to store any secrets on GitHub or with integrators like Vercel. Just send a payload to your own endpoint each time a commit is made, and that can trigger your shell script to rebuild and deploy. Using symbolic links helps make it more robust to errors. Trigger a pull of the repo, and build. Only if the build is successful, move the symbolic link of your production app to the new build. This also allows keeping some history of builds in case you ever need to troubleshoot.
My deployment platform is a shell script
31–40 of 141 posts
Re: My deployment platform is a shell script
#32For PHP https://deployer.org
For JS https://webpod.dev
Re: My deployment platform is a shell script
#33The use of ls in this way is not good form:
cd /root
for project in $(ls go-cicd);
for project in ./*
do [ -d "$project" ] || continue
...Re: My deployment platform is a shell script
#34Why not use Ansible for something like this?
Don’t get me wrong, I love bash scripts like any other old hat, but Ansible scratches this exact itch.
You’ve got playbooks that can execute shell, provide logging, better management, history of execution, fleet management, and it’s light weight. And there’s a robust community of shared modules, etc.
Re: My deployment platform is a shell script
#35Why not use Ansible for something like this? Don’t get me wrong, I love bash scripts like any other old hat, but Ansible scratches this exact itch. You’ve got playbooks that can execute shell, provide logging, better management, history of execution, fleet management, and it’s light weight. And there’s a robust community of shared modules, etc.
Why add the complexity of having to maintain an Ansible installation, a logging stack, deal with their upgrades and whatever python issue one might encounter. I had the issue of Ansible builtin `shell` not doing the right thing (sh vs bash) or it being unnecessarily slow when uselessly looking up `cowsay`.
Adding layers and layers of tooling is often overkill and it is hard to bit the simplicity of 33 lines of shell when the use case is a single person doing the code, deployment and maintenance.
Re: My deployment platform is a shell script
#36I assume this script runs on the server. I was building Go projects on the server as well, a vps where I have several things running. At some point I noticed that larger builds severely effected the other websites. So now I build locally and push the binary to git. To not bloat the project repo with big binary blobs I use a special deploy repo.
Re: My deployment platform is a shell script
#37my script will never: - go down - require an upgrade - force me to migrate - surprise me - keep me up at night Oh my sweet summer child.
but my server will:
- require direct source code access
- require go build tools
- require maintaining GitHub auth
- require upgrading build tools over time
- not be trivial to rebuild on failureRe: My deployment platform is a shell script
#38Why not use Ansible for something like this? Don’t get me wrong, I love bash scripts like any other old hat, but Ansible scratches this exact itch. You’ve got playbooks that can execute shell, provide logging, better management, history of execution, fleet management, and it’s light weight. And there’s a robust community of shared modules, etc.
I think Ansible is a little overkill for some projects tbh. Ideally I'd love a middle ground between bash scripts and Ansible, similar to Caddy's config simplicity over nginx.
>it’s light weight
Eh, don't think that's the case for everyone.
I dabbled with Ansible at a previous job, and set up a very basic personal server setup for Nextcloud and one other app. It was much slower than if I had just written some bash scripts. Idempotency was nice, but the feedback loop wasn't great.
Re: My deployment platform is a shell script
#39For PHP https://deployer.org For JS https://webpod.dev
Laravel has Envoy as well: https://laravel.com/docs/11.x/envoy
I've played around a bit with Deployer for some projects. It's decent, but feels brittle. It's very dependent on you sticking with its assumed default setup, docs are all over the place, and extending/replacing scripts I found confusing.
I moved back to bash scripts.
Re: My deployment platform is a shell script
#40I 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 server provisioning & deployments are done by bash scripts over SSH. Excluding comments/spacing, the provisioning script is 35 lines of mostly installing dependencies and minor file template copies. For simpler projects not needing queue workers and/or not using more "exotic" tech like Laravel Octane, this could probably be cut down to 30.
TL;DR do the simplest thing that works for you and move on with life - the value in your project, if you intend to deploy it, is for it to be used.