If the tool you use does not support continuous delivery values, you're going to have a bad time implementing CI/CD with fully automated pipelines.
Here are some rules for the road:
- The first rule is: Don't select your toolchain until you have designed the pipeline you want to have
- Every action or configuration can become code in source control so you can version things and get an audit trail on changes
- Everything that can be invoked or configured has an automation end point through command line or APIs
- Every command line can return zero for success or non zero for failures
- If you have to log in to a UI to be able to configure or execute something, you're going down the wrong path - Your CI/CD tools (like Jenkins) is your user, not humans.
- Queues should be avoidable: if you can only do one task at a time, but you have multiple builds that need to use the tool, you'll have a queue. The tool should be able to support parallel work by multiple pipelines or any other support for avoiding such queuing - as long as it enables pipelines to run faster, not slower, but still give all the feedback you need into the pipeline.
- Results should be easily visible in the pipeline, or importable via API or command line: You need to be able to see the results easily in the pipeline log so that you can easily understand pipeline issues without going through different teams and tools.