I'm really surprised to see this as the top comment. I've spent my career specializing in most of your bullet points. Lately I've been meaning to start a tutorial series with either those concepts or general "learn to code" kind of stuff. Clearly there is more interest in the operations type content than I would have guessed.
> I'm really surprised to see this as the top comment.
Me too. I consider most of these trivial too. But there's another aspect. Many things (version control flow, release model, rollbacks, etc) has to take into consideration and will inevitably affect the workflow, meaning the way engineers write code (feature flags? dynamic config? gitOps? what about rollbacks? Do we keep the tip of the branch synced with prod or no?).
The _state of art_ is different based on things like: Monolith or micro-service (like smaller, well defined scope)? Is the app written in Java, NodeJS or Python? Do we have 5 developers, 1 or 400? Do we need to testing because the app is handling medical data or we don't care if we don't case because our SaaS doesn't handle sensitive data? Do we need integration tests? Do we care about raw computation perf? Mem leaks? What about testing thresholds?
All the above and many more, depend on business goals and domains, engineering cultures and less obvious intangibles. These evolve "naturally" over time.
There's no "state of art", just business needs. The "state of art" is the sweet spot between engineering velocity and reliability, which is a moving target anyway :-)
