This is industry wide issue. Working on a much larger project
old school version SRE team of 4 managed all the infra. "Cloud Native" version team of 7 DevOps 1.5 years building out CI/CD setup that is still somewhat iffy.
I've experienced similar projects. Big microservices, multi-engineering team, full time SRE team etc... but it was basically a CRUD system, all the heavy lifting was done by an old mainframe black box system, hidden away by yet another old Java application.
It was a lot of engineers flexing. And of course, the same engineers that started it had moved on to greener pastures well before the system went live and was tested by real life and real customers.
I think I've finally grown enough of a pair to never tolerate something like that. Prove that you need microservices first. Prove that you - prove that the organization - can manage the overhead and complexity.
I feel much less like an impostor when I read this. Thanks, HN!
Is it even worth it adopting ci/cd for my small craft or am I fine sticking with push, ssh, pull, [vi config.json]? What do they actually achieve with it?
Think of it in terms of principles. Why do we do continuous delivery in the most abstract sense? To get real value out of, and production feedback from, your code as quickly as possible. Both of these always help you write higher-quality code.
The ideal is deploying every single commit. What could prevent you from this? Primarily two things:
1. You risk screwing the process up, causing expense in terms of damage to customers.
2. You don't like how much work it is to deploy every single commit; the transaction cost, even when everything goes right, is too high for your personal tastes.
Continuous delivery automation tooling helps with these two issues. If they are not problems (in other words, you do things right every time and you don't mind doing it manually for every commit) then you don't have the problems tooling would solve, so no reason to use said tooling.
Continuous integration is different from continuous delivery, and more about coding patterns than automation.
If you find yourself adding errors to your code that would have been caught with some basic testing that you usually do (or want to do) but forgot to do or were too lazy to do, then add some tests using whatever the typical framework is for the language you are on. Maybe do some simple github actions CI - it's pretty easy and a decent skill to have regardless.
Having "unit" tests is a good habit to get into no matter what, really, but that doesn't mean you need a bit CI/CD pipeline. CD isn't really needed until the creation of your application is complex, or you have actual customers/users that depend on it.
Do push, ssh, pull receive any parameter that may cause your program to misbehave if you get it wrong? If yes, then it's worth automating, if no, then no.
Anyway, would you call putting the entire interaction in a shell script "ci/cd"?
If yes, then you have an acknowledged risk. That doesn't immediately say you should automate it - depends on the cost and _risk introduced_ by the automation.
