5 ms·

Why don't we run it on every change?

bryanrasmussen 7y ago
If a build takes 4 hours it argues that a build on that system is a pretty expensive operation, unless changes are very infrequent, which in most systems is not the case, a build run on every change would seem to be highly problematic.
- tlarkworthy 7y ago
  Bingo it's expensive, which is why they set it to every 24 hours. Also coz they don't want to add the queuing logic, so it takes 4 hours to run is an approximation. Also it messes with other systems so they prefer to run it overnight. This blog doesn't solve a real problem.
  - royosherove 7y ago
    Author here. It's literally the first line in the blog post. And it links to this blog post about static environments: https://pipelinedriven.org/article/the-four-biggest-issues-with-having-static-environments https://pipelinedriven.org/article/the-four-biggest-issues-w...
    - tlarkworthy 7y ago
      That doesn't answer anything. Either you: minimize latency (run every change independent of build time) or run to minimize engineering (24 hours). I dunno why you couple build time to a static period, it does not make sense to me.
- lonelappde 7y ago
  Builds are cheap compared to running in production. Stop being a cheapskate.
  - bryanrasmussen 7y ago
    I don't understand your running in production comment in this context, nor actually your stop being a cheapskate aimed at me.
royosherove 7y ago
That would be ideal, but many organizations don't yet have that capacity for large builds/deploys (yet).
eska 7y ago
It's a bandwith vs latency issue. Imagine you make 5 commits in 4 hours. You now have 5 builds queued up and 20 hours of latency. So one would probably prefer to only build the last commit, and maybe queue the older commits up for later. But if you make another change then you'd need to pause the build of the older commit, or you'd be at up to 8 hours of latency instead of 4..
- gpvos 7y ago
  If you do them in parallel, your latency is still 4 hours. Okay, it's not cheap.

If a build takes 4 hours it argues that a build on that system is a pretty expensive operation, unless changes are very infrequent, which in most systems is not the case, a build run on every change would seem to be highly problematic.

tlarkworthy 7y ago
Bingo it's expensive, which is why they set it to every 24 hours. Also coz they don't want to add the queuing logic, so it takes 4 hours to run is an approximation. Also it messes with other systems so they prefer to run it overnight. This blog doesn't solve a real problem.
- royosherove 7y ago
  Author here. It's literally the first line in the blog post. And it links to this blog post about static environments: https://pipelinedriven.org/article/the-four-biggest-issues-with-having-static-environments https://pipelinedriven.org/article/the-four-biggest-issues-w...
  - tlarkworthy 7y ago
    That doesn't answer anything. Either you: minimize latency (run every change independent of build time) or run to minimize engineering (24 hours). I dunno why you couple build time to a static period, it does not make sense to me.
lonelappde 7y ago
Builds are cheap compared to running in production. Stop being a cheapskate.
- bryanrasmussen 7y ago
  I don't understand your running in production comment in this context, nor actually your stop being a cheapskate aimed at me.

royosherove 7y ago

That would be ideal, but many organizations don't yet have that capacity for large builds/deploys (yet).

eska 7y ago

It's a bandwith vs latency issue. Imagine you make 5 commits in 4 hours. You now have 5 builds queued up and 20 hours of latency. So one would probably prefer to only build the last commit, and maybe queue the older commits up for later. But if you make another change then you'd need to pause the build of the older commit, or you'd be at up to 8 hours of latency instead of 4..

gpvos 7y ago
If you do them in parallel, your latency is still 4 hours. Okay, it's not cheap.