- if i use state of the art production grade technology i can talk about it in interviews, if i say oh well i have plenty experience running docker compose manually on a server, not so much. This is also where new technology can be tested without hurting someone, so even if something is totally overkill it can still make sense in the overall picture of all projects you work on
- ci/cd is maybe not relevant to your users, but its about your own sanity, it forces complete documentation in code of what is done to build and ship, decouple it from local dev setups and make as deterministic as possible. Even small project benefit, have you ever come back after 2 years and took hours to remember the order of voodoo commands or lost a laptop and then had to install specific versions of cli tools?
- the logic is totally changed by the simplicity of faas offerings. Nowadays i would maybe not build a gigantic kubernetes system, but instead of dealing with vms and servers skip right to cloudfare workers or cloud run and have the same benefits of k8 with even less work and more time to work on the features
>- ci/cd is maybe not relevant to your users, but its about your own sanity, it forces complete documentation in code of what is done to build and ship, decouple it from local dev setups and make as deterministic as possible. Even small project benefit, have you ever come back after 2 years and took hours to remember the order of voodoo commands or lost a laptop and then had to install specific versions of cli tools?
This to me is the biggest advantage of this sort of thing. Documentation and notes are great, but I'd rather just have the thing-in-itself available that does the job.
I can go back to projects I wrote 10-14 years ago, and the same build/deploy scripts still work today. I used standard POSIXy or GNU tools back then. They still work the same way today.
It really depends on how you pick what you depend on. Would some random third party CI/CD infrastructure, I might have selected 10 years ago still work or be in business today? Hard to say. Maybe I would have picked something that stayed supported until this day, maybe not...
Yeah and 13 years ago there was a similar argument about git. I heard a lot of developers say well its a small project and its just me, no way i'm dealing with repos, making commits and learn git or mercurial. This completely died out.
Perhaps in the resume/interview best to highlight outcomes (supported N users with 99.9% availability solo with $x a month spend) in favor of tech used. "Evaluated kubernetes and [tech du jour]" also gets the keywords in there.
- if i use state of the art production grade technology i can talk about it in interviews, if i say oh well i have plenty experience running docker compose manually on a server, not so much. This is also where new technology can be tested without hurting someone, so even if something is totally overkill it can still make sense in the overall picture of all projects you work on
- ci/cd is maybe not relevant to your users, but its about your own sanity, it forces complete documentation in code of what is done to build and ship, decouple it from local dev setups and make as deterministic as possible. Even small project benefit, have you ever come back after 2 years and took hours to remember the order of voodoo commands or lost a laptop and then had to install specific versions of cli tools?
- the logic is totally changed by the simplicity of faas offerings. Nowadays i would maybe not build a gigantic kubernetes system, but instead of dealing with vms and servers skip right to cloudfare workers or cloud run and have the same benefits of k8 with even less work and more time to work on the features