You mentioned a lot of good things. There's some that will cause frustration and failures if embraced, plus they go against the fundamentals of DevOps...
2 - Your infra should be able to handle a failed deployment automatically and rollback. If it can’t, you’re doing it wrong.
12 - Do not automate a bad process, you end up with an automated bad process
16 -If you need to SSH into your VM then your automation is failed.
All of those are the opposite of DevOps. DevOps, as anything in life or software, is a progression. All three of the above imply that we can wave a magic wand and things will be at 100% satisfaction instantly. I'll comment on each one, in the hopes of bringing some DevOps clarity...
2 - Your infra should be able to handle a failed deployment automatically and rollback. If it can’t, you’re doing it wrong.
The first step in DevOps/CD is to have an automated deploy, not have one that is also revertible. One of the most important aspects to learn about DevOps, is it's not about rules and regulations, it's about the Journey to be be better, with a set of goals in mind. #2 above is important, but it's not "doing it wrong" or "failed" if you don't achieve that right out of the gate. In fact, I'd argue that if you rush into that, you'll have a tangled web of nastiness to cleanup after the fact. This actually leads into comments for #12 as well, which will shed more light on the matter.
12 - Do not automate a bad process, you end up with an automated bad process
This one would really fall into proper practices on "refactoring". If you have a bad process, you absolutely should automate that bad practice first, and "as is". That way, you start off with something familiar, something that you know works, etc, no matter how non-idealistic it is, before you start refactoring it. And, in the process of building that "bad process" you learn all the nitty gritty details about why it's bad, which will help you plan to get away from it. This is one of those foundational refactoring strategies; start with what is working now, and slowly, incrementally, move to something better!
16 - If you need to SSH into your VM then your automation is failed.
Again, this seems to imply there's a magic wand that we can somehow get from where we are now, to a perfect state. Did you know that AWS recommends having a way of SSHing into your ECS containers if necessary, for diagnostics purposes? You absolutely must have a way of getting into your containers, but you should also avoid the need to do so by incrementally improving your systems to handle problems automatically.
You mentioned a lot of good things. There's some that will cause frustration and failures if embraced, plus they go against the fundamentals of DevOps...
2 - Your infra should be able to handle a failed deployment automatically and rollback. If it can’t, you’re doing it wrong.
12 - Do not automate a bad process, you end up with an automated bad process
16 -If you need to SSH into your VM then your automation is failed.
All of those are the opposite of DevOps. DevOps, as anything in life or software, is a progression. All three of the above imply that we can wave a magic wand and things will be at 100% satisfaction instantly. I'll comment on each one, in the hopes of bringing some DevOps clarity...
2 - Your infra should be able to handle a failed deployment automatically and rollback. If it can’t, you’re doing it wrong.
The first step in DevOps/CD is to have an automated deploy, not have one that is also revertible. One of the most important aspects to learn about DevOps, is it's not about rules and regulations, it's about the Journey to be be better, with a set of goals in mind. #2 above is important, but it's not "doing it wrong" or "failed" if you don't achieve that right out of the gate. In fact, I'd argue that if you rush into that, you'll have a tangled web of nastiness to cleanup after the fact. This actually leads into comments for #12 as well, which will shed more light on the matter.
12 - Do not automate a bad process, you end up with an automated bad process
This one would really fall into proper practices on "refactoring". If you have a bad process, you absolutely should automate that bad practice first, and "as is". That way, you start off with something familiar, something that you know works, etc, no matter how non-idealistic it is, before you start refactoring it. And, in the process of building that "bad process" you learn all the nitty gritty details about why it's bad, which will help you plan to get away from it. This is one of those foundational refactoring strategies; start with what is working now, and slowly, incrementally, move to something better!
16 - If you need to SSH into your VM then your automation is failed.
Again, this seems to imply there's a magic wand that we can somehow get from where we are now, to a perfect state. Did you know that AWS recommends having a way of SSHing into your ECS containers if necessary, for diagnostics purposes? You absolutely must have a way of getting into your containers, but you should also avoid the need to do so by incrementally improving your systems to handle problems automatically.
Nicely put, DevOps is truly a journey.