We have experience working with big variety of teams with different workloads. It allowed us to have wider view on building CI/CD compared to companies that work only with mid-size clients for example. Our most interesting and largest projects were where we need to create our own CI/CD system based on existing ones because of big number of builds and concurency that client wanted. When you work with big amount of commits/pushes you need to build kind-of even-driven CI/CD system with proper triggers, waiting queues and so on, so you don't make developers life more complicated due to CI/CD pipeline limitations.

We cannot recommend one or couple specific tools because they always change. At the moment of writing there are couple of market leaders as Jenkins and GitlabCI, but there are many others that can fulfil your needs in CI/CD system. With evolution of Kubernetes there are more and more companies who try to adopt the GitOps approach and new tools are emerging , such as Jenkins X, ArgoCD, Flux, Spinnaker. The main criteria you should look for is how easy it is to customize the CI/CD tool you will use, and how much of that customization you will need. Everything else is very specific to the company and product you would like to build, for some people simple TravisCI may be enough to build the ruby code and deploy it somewhere, and for other company building 100 microservices - you would need tool like Jenkins with ability to add your own custom logic into the CI/CD process.

These are the two terms that can be easily confused and we really love discussing this question on our interviews because it allows to understand how deep our engineers understand the CD processes. In simple words - main difference between the terms is completely automated pipeline vs automated pipeline with someone going and pushing the red button. Continuous Delivery is the first case - where you have no manual intervention to your pipelines.
Continuous Deployment is the second case - you can automate everything you can but as long as you have some approval procedure - this will be the Continuous Deployment. And we are not saying it's bad, for some types of systems/platforms this is the only way to deliver new versions to end users.

Yes, QA team is the most important part in building robust CD system. Continuous Integration completely is on developers because you need to maintain quality of the code you build, and how you do it - it's up to you, or up to principles that you adopt in your company. But when we are talking about Continuous Delivery/Deployment you need to involve the QA team a lot, since it's their responsibility to make sure that new version is giving more positive effects than negative and decide whether to deploy it or not. Whether this process manual or automated - doesn't matter much, the most important - don't try to think that you have developers that can be sure in the quality of their code. There always should be some specialist who can ensure this.

No, you don't have to automate everything in your system. For sure it is great to have everything covered by the tests, but if you are limited in resources - try to make automation around the most basic and most important logic of your application/platform. This will allow you to save QA team time from release to release, and focusing on the rest cases that matter, while you are sure your application is still working as expected, or if it's not you atuomatically get notified about this, before releasing it to production.