@vaporeon_ a hellscape of configuration files and misery
@vaporeon_ complicated DevOps configurations are worth doing in large software teams but it is often overengineering to do so on a personal project
@wallhackio True, but I think that basic testing would still be a good thing to do, especially for something like the Mastodon client that's exposed to untrusted input from the web
The thing that I specifically wanted to look into is called fuzzing as far as I know, giving the program a bunch of unexpected input and seeing whether it does the right thing or whether it crashes and burns and possibly segfaults
@vaporeon_ I am doing a teeny bit of DevOps shit for my blog's build pipeline, so yeah it's not like you should avoid it entirely
@wallhackio @vaporeon_ a more traditional model of software development conceives of software as a purroduct developed in stages; in purrticular, development and opurrations (that is, maintanence, suppurrt, the shit IT handles really) are completely sepurrate stages. the entire point of a DevOps culture is to integrate development and opurrations; the development lifecycle is generally much shorter; purrocesses are automated (especially testing and deployment); the hope is to find and fix purroblems faster, and deploy new changes more quickly and correctly
@vaporeon_ DevOps is good and important but I personally dislike managing it.
It's easiest to describe DevOps through example. It's when you do things like have gitlab run a test suite when you push to a certain branch