Is it a good idea to make Ansible and Rundeck work together, or using either one is enough?
Solution 1:
TL;DR - given your environment of Jenkins for CI/CD I'd recommend using just Ansible.
You've spotted that there is sizeable cross-over between Ansible & Rundeck, so it's probably best to concentrate on where each product focuses, it's style and use.
Focus
I believe Rundeck's focus is in enabling sysadmins to build a (web-based) self-service portal that's accessible to both other sysadmins and, potentially, less "technical"/sysadmin people. Rundeck's website says "Turn your operations procedures into self-service jobs. Safely give others the control and visibility they need.". Rundeck also feels like it has a more 'centralised' view on the world: you load the jobs into a database and that's where they live.
To me, Ansible is for devops - so building out and automating deployments of (self-built) applications in a way such that they are highly-repeatable. I'd argue that Ansible comes more focussed for software development houses that build their own products: Ansible 'playbooks' are text files, so normally stored into source control and normally alongside the app that the playbooks will deploy.
Job creation focus
With Rundeck you typically create jobs via the web UI.
With Ansible you create tasks/playbooks in files via a text editor.
Operation/Task/Job Style
Rundeck by default is imperative - you write scripts that are executed (via SSH).
Ansible is both imperative (i.e. execute bash statements) but also declarative, so in some cases, say, starting Apache you can use the service task to make sure that it's running. This is closer to other configuration management tools like Puppet and Chef.
Complex jobs / scripts
Rundeck has the ability to run another job by defining a step in the Job's workflow but from experience this feels like a tacked-on addition than a serious top-level feature.
Ansible is designed to create complex operations; running/including/etc are top-level features.
How it runs
Rundeck is a server app. If you want to run jobs from somewhere else (like CI) you'll either need to call out to the cli or make an API call.
Straight Ansible is command-line.
Proviso
Due to the cross-over and overall flexibility of Rundeck and Ansible you could achieve all of the above in each. You can achieve version control of your Rundeck jobs by exporting them to YAML or XML and checking them into source control. You can get a web UI in Ansible using Tower. etc. etc. etc.
Your questions:
Complementary tools?
I could envision a SaaS shop using both: one might use Ansible to perform all deployment actions and then use Rundeck to perform one-off, adhoc jobs.
However, while I could envision it I wouldn't recommend that as a starting point. Me, I'd start with just Ansible and see how far I get. I'd only layer in Rundeck later on if I discovered that I really, really need to run one-offs.
CI/CD
Ansible: your environment sounds more like a software house where you're deploying your own app. It should probably be repeatable (especially as you're going Continuous Delivery) so you'll want your deploy scripts in source control. You'll want simplicity and Ansible is "just text files". I hope you will also want your devs to be able to run things on their machines (right?), Ansible is decentralised.
Used together (for CI/CD)
Calling Rundeck from Ansible, no. Sure, it would be possible but I'm struggling to come up with good reasons. At least, not very specialised specific-to-a-particular-app-or-framework reasons.
Calling Ansible from Rundeck, yes. I could envision someone first building out some repeatable adhoc commands in Ansible. Then I could see there being a little demand for being able to call this without a command line (say: non technical users). But, again, this is getting specific to your environment.
Solution 2:
My point - rundeck and ansible (free, without tower) do different kind of job
Ansible (without tower) - configuration management ( server / app provision, mass config updates)
Rundeck - Centralized job scheduler with access control, notification, job output etc. (archive old logs, run some scripts etc.)