Today, you could more or less setup a CI/CD toolchain by youself, even locally. Indeed I have seen teams doing it in an ITSM environment because the communication with management did not work.

Nevertherless we know CI/CD is a very important, if not most important, company production line - it produces value, even if it is not seen so by ITSM to give it operations status and priority (in short, SLA for systems which should survive project time instead of setting them up in every project and department over and over).

Let's ignore for simplicity network downloads.

Question: what should be the execution speed of CI/CD relative to a setup on a local machine (if possible):

  • Same is ok?
  • Faster - how much faster?
  • Slower?
  • 1
    I'm having a hard time imagining a reason why CI/CD should be slower than a local machine :) (Other than due to budget constraints.) An important factor is that this system will typically be supporting builds for multiple developers/projects, so that ought to be factored into the spec. Commented Nov 19, 2017 at 10:24

2 Answers 2


You want the execution speed of the CI pipeline as fast as (practically) possible, irrespective of being a local or shared setup or the time required to set it up - this is what effectively dictates the overall development speed in the respective project.

But it should be noted that by speed here I don't mean the duration of each CI execution. The duration of such execution may be directly related to the coverage of the CI QA verification, which translates into stabiliity of the development process and the quality of the product. For example including a smoketest in the CI verification will increase the duration of the CI execution, but will also raise the product quality - it's a good thing.

But I have to mention: such private CI setups (even those SLA-backed CI setups you mention) are often an indication of what the ThoughtWorks team called the CI Theatre. Simply using CI tools doesn't make the process a CI one. Using project/feature/integration branches which still require subsequent branch merges (other than cherry-picked fixes) before release means development is still done in silos (those branches are the silos) - waterfall style.

Side note: Frankly, if I'd be part of a team in which management doesn't understand the importance of CI (let alone not being able to effectively communicate on such critical subject) I'd look for another job - I doubt they'll remain in business for very long ;)


They should be roughly equal.

If the CI system is faster than running it locally, your local development is going to be uncomfortably slow.

If your CI system is much slower than running it locally, it will become something that is an obstacle rather than something provides value.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.