How relevant become the DoD and DoR if we we want to go the way of CI/CD?
The Definition of Done has the same relevancy as if you aren't doing Continuous Integration/Continuous Deployment (CI/CD). This is from the Scrum Guide
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
So, in CI/CD you could be releasing multiple increments in a single Sprint.
As for the Definition of Ready, that is not a concept identified in the Scrum Guide. I have used them in the past as a practice that my team wanted. We used it to help identify Product Backlog Items that were "ready to be included in a Sprint". If that is the way you are using it, then I don't see how its relevancy would be changed by CI/CD. If you are using it in some other way, you need to provide more information for me to form an opinion.
I don't think the relevancy changes.
The Definition of Ready isn't a term or concept defined in the Scrum Guide, which states that a Product Backlog Item is ready for selection at Sprint Planning when the Scrum Team believes it can be completed within one Sprint. I'd consider the use of a Definition of Ready to be a complementary practice (and one that should be used with caution). I'm not able to readily think of ways I would change the Definition of Ready as I move from not having continuous integration all the way to continuous deployment.
The Definition of Done, as a concept, doesn't change. However, I can see the need for having a stringent Definition of Done become more important and a change to when the Definition of Done needs to be satisfied. If you are deploying on every successful commit (as you would in Continuous Deployment), you're going to want to make sure that each change - each commit - meets the Definition of Done at the time that the commit is made. That means reviews, tests, documentation updates, and anything else the team needs, is complete and satisfactory when the commit is made so that the commit has a high likelihood of being good.
How relevant become the DoD and DoR if we we want to go the way of CI/CD?
That depends. How keen are you on building a pipeline that squirts out oodles of technical debt?
Other have cautioned the use of a Definition of Ready (DoR) for good reason. While there are helpful complimentary practices used with Scrum (e.g. TDD, pairing, Flow practices, hypothesis driven development, etc.), the DoR could be used as a gate to stopping the flow of value.
Let's say the DoR for a Scrum Team states a Product Backlog item must be sized and have acceptance criteria before it is discussed by the Developers in Sprint Planning, amongst other things. Why couldn't the Scrum team refine this PBI in Sprint Planning? Why should they delay value for another Sprint? How agile would we be if a strict gate was put up in front of us?
I'm not saying we should skip refinement activities and refine every single PBI in Sprint Planning. We work in a world of complexity and uncertainty, and need to be able to respond to change and have some flexibility.