<p>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.</p>

<p>But it should be noted that by speed here I don't mean the <em>duration</em> 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.</p>

<p>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 <a href="https://www.gocd.org/2017/05/16/its-not-CI-its-CI-theatre.html" rel="nofollow noreferrer">the CI Theatre</a>. 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. </p>

<p>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 ;)</p>

CC BY-SA 3.0
2017-11-19T16:28:54.423Z
2017-11-19T16:28:54.423Z
Dan Cornilescu
<p>They should be roughly equal.</p>

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

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

CC BY-SA 3.0
2017-11-19T22:55:24.333Z
2017-11-19T22:55:24.333Z
user2640621
<p>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.</p>

<p>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).</p>

<p>Let's ignore for simplicity network downloads.</p>

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

<ul>
<li>Same is ok?</li>
<li>Faster - how much faster?</li>
<li>Slower?</li>
</ul>

CC BY-SA 3.0
2017-11-19T10:24:36.833Z
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.
Oliver Charlesworth
<methodology>
What is the optimal speed relation of CI/CD jobs to a (reference) local machine?
Ta Mu
# What is the optimal speed relation of CI/CD jobs to a (reference) local machine?

(Asked by: username_0 on 2017-11-19)

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?

**Tags:** methodology

> **Comments:**
> **username_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.  

---

## 2 answers

### Answer by username_2 on 2017-11-19. Score: 3

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](https://www.gocd.org/2017/05/16/its-not-CI-its-CI-theatre.html). 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 ;)


---

### Answer by username_3 on 2017-11-19. Score: 0

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.


---

