6 ms·
Friendly reminder of the day: Always have an established and regularly tested workflow for manual deployments that doesn't rely on CI jobs. You'll need it soon
by the_duke 4y ago
Friendly reminder of the day:
Always have an established and regularly tested workflow for manual deployments that doesn't rely on CI jobs. You'll need it sooner or later.
- rozenmd 4y agoYour CI should be the automation of an existing, manual process for this reason. Should the automation fail, your manual process still works.
- deleted 4y ago[deleted]
- pid-1 4y agoThat's why my CI pipelines never rely on proprietary stuff. I use multistage Dockerfiles + Buildkit to implement secrets caching, etc... My CI scripts just do "docker build" and "docker publish". It makes doing things locally much easier.
- imdsm 4y agoI've always resisted the change to GHA, preferring instead tried and tested Jenkins and docker workflows. Sure, multi-agent GHA is nice, but when it's down, what do you do? We don't even work in offices to have swordfights in anymore.
- zinekeller 4y agoI agree here, looking now it seems that I would need three pairs of hands to count how many times Actions have gone down every year. It feels like Actions itself is not ready for production use. Also nice XKCD reference (https://xkcd.com/303/ https://xkcd.com/303/)!
- mrweasel 4y agoI wasn't aware that there's a "docker publish" command. Is that an add-on or how does that work?
- yellow_lead 4y agoSCP, SSH, and cp to the rescue
- madjam002 4y agoAnyone recommend any tools that can do CD pipelines on the CLI, maybe something a bit nicer than Makefiles?
- jordemort 4y agoI’m liking Earthly a lot: https://earthly.dev/ https://earthly.dev/
- AbhyudayaSharma 4y agoJenkinsfile Runner is exactly that! https://github.com/jenkinsci/jenkinsfile-runner/ https://github.com/jenkinsci/jenkinsfile-runner/
- neolithicum 4y agoThere's also taskfile. https://taskfile.dev/ https://taskfile.dev/
- the_duke 4y agohttps://dagger.io https://dagger.io
- major505 4y agoOr a shell script. Always have a backup shell script.
- roomey 4y agoProblem is who will maintain and test it. Without DR (disaster recovery) test days its worth nothing cause something will have been changed and not propagated
- plonk 4y agoUse the script in your regular CI/CD pipeline. Just add arguments for things that vary between GitHub runners and local machines, like secrets and paths.
- yakak 4y agoIt's certainly a risk to be relying on any proprietary SaaS or Cloud but I don't really get the reason to be doing CI/CD as if it can never be down. There are a lot of risks in having credentials on hot spare alternative systems you rarely need and the number of times I've really had to rollback a deployment quickly is something I can count on one hand. Isn't it better to focus on quality to not need to deploy on a moment's notice?
- plonk 4y agoYou can keep the credentials in a password manager. Presumably the sysadmin already uses the same corporate PM for his regular credentials, so this doesn't increase risk much. We're a small org but I'd be pretty annoyed if we planned a deployment on a day and ended up having to wait for GitHub to go back up. Deployments can be disruptive and we have to coordinate with other teams.
- mrweasel 4y agoI feel like most of my build or deployment pipelines always end up as just a bash script executed by the CI/CD tool anyway.