> something that executes the docker build and then kicks the jobs off - right?
yep. there's build time and deploy time.
build time generally coincides with peer review: build happens because someone changes something, all changes are version controlled and get peer reviewed. so it's usually some combination of tools that can be integrated with and triggered by the code review tool. in prehistoric times the code review tool might trigger a CI workflow in jenkins which invokes a glue shell script to invoke specific build or test tools. these days the runner might be more tightly integrated into the code review system, such as a github or gitlab runner + using the runner's proprietary scripting language to call the same glue shell script to invoke the build tools.
At $day job the deploys that change real world state are coordinated and triggered by a meat layer of humans, they're not automatically triggered by commits getting merged, etc. A workflow automation system roughly equivalent to prehistoric jenkins is used to define manually triggered deployment jobs that are used to deploy to environments, those deploy jobs will typically invoke some kind of glue shell script that invokes terraform or kubectl or whatever, which will have the responsibility of coercing the environment into the desired state.
