<p>I would separate the CI and CD contexts, as the periodicity in one of them is rather loosely coupled to the periodicity in the other one. </p>

<p>That's primarily because CI attempts to produce versions of software <em>available</em> for delivery/distribution, see <a href="https://devops.stackexchange.com/questions/488/how-does-continuous-integration-relate-to-continuous-delivery-deployment/493#493">How does continuous integration relate to continuous delivery / deployment?</a>
But not all CI executions are successful. CD periodicity will, at best, be equal to the CI one, but typically it will be lower.</p>

<p>In CI the periodicity is tightly coupled to the desired development velocity (and maybe branch stability) and can be driven by different project-specific requirements. Here are just some examples of CI execution patterns, there could be others:</p>

<ol>
<li><p>launched for every changeset commit - the recommended one, as it offers the shortest time to identify a changeset causing a regression, see <a href="https://softwareengineering.stackexchange.com/questions/334574/build-on-each-commit-continuous-delivery">Build on each commit - Continuous delivery</a>. Costs vary with the commit rates.</p></li>
<li><p>launched every <code>N</code> (fixed number of) commits - trade culprit identification performance of #1 for slightly lower costs (overall fewer executions)</p></li>
<li><p>launched every <code>T</code> (fixed) time interval</p>

<ul>
<li>fixed costs due to predictive amount of executions: no cost hikes for commit activity peaks, a day with twice the number of commits than another will still cost the same</li>
<li>culprit identification performance drops vs #1 if multiple changesets are committed within <code>T</code></li>
<li>consecutive executions without any changeset committed in between offer measurements of the verification process reliability - different results in such executions could indicate unreliable verifications</li>
</ul></li>
<li><p>launched whenever resources for execution are available - if that's where the bottleneck of the process lies. Any of the above categories can appear depending on the pattern of commits relative to the intervals between executions. This maximizes the verification resources ROI.</p></li>
<li><p>launched with one pattern during working hours and a different pattern overnight - to balance computing resources utilisation, for example.</p></li>
</ol>

<p>Another possible reason for periodicity mismatch between CI and CD is the variability in the duration of the CI executions. Caused, for example, by that prohibited build schedule policy you mentioned (see also <a href="https://devops.stackexchange.com/questions/513/how-to-implement-a-frozen-test-environment">How to implement a frozen test environment?</a>) Or by builds executed on classes of servers with significantly different performance, thus lasting different amounts of time.</p>

<p>Even for a successful CI execution in which the produced software version qualifies and is available for deployment it doesn't necessarily mean it will also be immediately deployed (or even deployed at all). There can be other criteria or policies preventing it (business reasons, for example).</p>

CC BY-SA 3.0
2017-03-19T13:15:23.180Z
Interesting examples! Any idea which one of them is closest to the example in my question? Seems to it is "3.", no?
Pierre.Vriens
CC BY-SA 3.0
2017-03-19T13:22:14.673Z
@Pierre.Vriens I'd model it with something alongside of #4 - just declare the resources unavailable during the intervals of interest. If you perform those tests as part of CI. If they're CD you might be able to control them in the sw/management system
Dan Cornilescu
CC BY-SA 3.0
2017-03-19T13:37:22.050Z
Well, that would have been my 2nd choice (I doubted). It reminds me about some (expensive) mainframe SCM processes that some bank ever imposed (forced), so that those processes were NOT allowed (= got deferred) to run on days where CPU usage was already extremely high due to end-of-month processing. And by those restrictions they were able to keep their monthy invoices from their mainframe vendor(s) within the budgets they had planned for.
Pierre.Vriens
CC BY-SA 4.0
2020-09-25T01:02:41.077Z
Seems to me that the execution patterns that are so well documented here are more like "Integration Execution Patterns", as they are not all continuous (like nightly builds #5)
jimmyjambles
CC BY-SA 3.0
2017-03-19T04:43:39.137Z
2017-03-19T04:43:39.137Z
2017-04-13T13:01:29.297Z
Dan Cornilescu
<p>I would hesitate to describe your once per day model as CI/CD, it sounds more like the "nightly build" model. </p>

<p>It really depends on the nature of your work and processes.  If things flow smoothly through building, testing, and preparation of an artifact for deployment and your development model / velocity isn't such that it would benefit from more frequent runs, I would say you have the spirit of CI/CD.</p>

CC BY-SA 3.0
2017-03-24T15:28:06.527Z
Well, your answer is indeed another way to look at it, and is also why I wonder about what I mentioned in my question. Merci anyway!
Pierre.Vriens
CC BY-SA 3.0
2017-03-24T15:16:50.210Z
2017-03-29T22:37:03.713Z
2017-03-29T22:37:03.713Z
Matt
<p>Periodicity will only come into effect if the overall integration and deployment processes take a long time to complete, which is more likely the actual problem.  Said differently, in an environment where applications are built using lightweight architectures that are quickly scanned, built, deployed and tested, periodicity would cease to be relevant.</p>
<p>I would say that periodicity prevents a system from being truly continuous, so that is the way in which they are related. PI/PD</p>

CC BY-SA 4.0
2020-09-25T00:58:07.810Z
2020-09-25T01:05:44.403Z
2020-09-25T01:05:44.403Z
jimmyjambles
<p>Part of what (I think) CI and CD is about, is processes that get repeated over and over again (= the "<em>continuous</em>" part of it). However continuous in this context is not exactly (I think) like a river where water keeps going (flowing) all the time. Instead it's rather something happening every X seconds, minutes, hours etc.</p>

<p>So assume some test-environment where every day, eg, from 5 pm to (max) 6 pm all required processes are executed to rebuild all executables that are impacted by the changed dependencies (sources, includes, etc), combined with appropriate CI/CD processes related to them. While before 5 pm and after 6 pm, none of these kinds of processes are allowed to be executed (eg to ensure the stability of the related environments).</p>

<p>Does such kind of periodicity (= between 5 pm and 6 pm, every day) fit with CI/CD or not? Or is it rather that periodicity has nothing to do with CI/CD?</p>

CC BY-SA 3.0
2017-03-18T19:05:59.343Z
I'd argue for no relation, as our CI/CD is triggered by each push on a repository, the product team is responsible of the impact of when they push. (Too short for an answer)
Tensibai
CC BY-SA 3.0
2017-03-18T19:20:54.320Z
@Tensibai interesting point, though instead of "no relation" maybe it's rather like "another example of periodicity is 'on demand' ...".
Pierre.Vriens
CC BY-SA 3.0
2017-03-18T19:27:40.090Z
Indeed, the question sounded heavily oriented on fixed schedule which was the point of my comment. Your variation is ok
Tensibai
<continuous-integration><continuous-delivery><continuous-deployment>
What's the relevance of periodicity in CI / CD processes?
Pierre.Vriens
# What's the relevance of periodicity in CI / CD processes?

(Asked by: username_0 on 2017-03-18)

Part of what (I think) CI and CD is about, is processes that get repeated over and over again (= the "*continuous*" part of it). However continuous in this context is not exactly (I think) like a river where water keeps going (flowing) all the time. Instead it's rather something happening every X seconds, minutes, hours etc.

So assume some test-environment where every day, eg, from 5 pm to (max) 6 pm all required processes are executed to rebuild all executables that are impacted by the changed dependencies (sources, includes, etc), combined with appropriate CI/CD processes related to them. While before 5 pm and after 6 pm, none of these kinds of processes are allowed to be executed (eg to ensure the stability of the related environments).

Does such kind of periodicity (= between 5 pm and 6 pm, every day) fit with CI/CD or not? Or is it rather that periodicity has nothing to do with CI/CD?

**Tags:** continuous-integration, continuous-delivery, continuous-deployment

> **Comments:**
> **username_1**: I'd argue for no relation, as our CI/CD is triggered by each push on a repository, the product team is responsible of the impact of when they push. (Too short for an answer)  
> **username_0**: @username_1 interesting point, though instead of "no relation" maybe it's rather like "another example of periodicity is 'on demand' ...".  
> **username_1**: Indeed, the question sounded heavily oriented on fixed schedule which was the point of my comment. Your variation is ok  

---

## 3 answers

### Answer by username_2 on 2017-03-19. Score: 4

I would separate the CI and CD contexts, as the periodicity in one of them is rather loosely coupled to the periodicity in the other one.

That's primarily because CI attempts to produce versions of software *available* for delivery/distribution, see [How does continuous integration relate to continuous delivery / deployment?](https://devops.stackexchange.com/questions/488/how-does-continuous-integration-relate-to-continuous-delivery-deployment/493#493)
But not all CI executions are successful. CD periodicity will, at best, be equal to the CI one, but typically it will be lower.

In CI the periodicity is tightly coupled to the desired development velocity (and maybe branch stability) and can be driven by different project-specific requirements. Here are just some examples of CI execution patterns, there could be others:

1. launched for every changeset commit - the recommended one, as it offers the shortest time to identify a changeset causing a regression, see [Build on each commit - Continuous delivery](https://softwareengineering.stackexchange.com/questions/334574/build-on-each-commit-continuous-delivery). Costs vary with the commit rates.
2. launched every `N` (fixed number of) commits - trade culprit identification performance of #1 for slightly lower costs (overall fewer executions)
3. launched every `T` (fixed) time interval

   * fixed costs due to predictive amount of executions: no cost hikes for commit activity peaks, a day with twice the number of commits than another will still cost the same
   * culprit identification performance drops vs #1 if multiple changesets are committed within `T`
   * consecutive executions without any changeset committed in between offer measurements of the verification process reliability - different results in such executions could indicate unreliable verifications
4. launched whenever resources for execution are available - if that's where the bottleneck of the process lies. Any of the above categories can appear depending on the pattern of commits relative to the intervals between executions. This maximizes the verification resources ROI.
5. launched with one pattern during working hours and a different pattern overnight - to balance computing resources utilisation, for example.

Another possible reason for periodicity mismatch between CI and CD is the variability in the duration of the CI executions. Caused, for example, by that prohibited build schedule policy you mentioned (see also [How to implement a frozen test environment?](https://devops.stackexchange.com/questions/513/how-to-implement-a-frozen-test-environment)) Or by builds executed on classes of servers with significantly different performance, thus lasting different amounts of time.

Even for a successful CI execution in which the produced software version qualifies and is available for deployment it doesn't necessarily mean it will also be immediately deployed (or even deployed at all). There can be other criteria or policies preventing it (business reasons, for example).

> **Comments:**
> **username_0**: Interesting examples! Any idea which one of them is closest to the example in my question? Seems to it is "3.", no?  
> **username_2**: @username_0 I'd model it with something alongside of #4 - just declare the resources unavailable during the intervals of interest. If you perform those tests as part of CI. If they're CD you might be able to control them in the sw/management system  
> **username_0**: Well, that would have been my 2nd choice (I doubted). It reminds me about some (expensive) mainframe SCM processes that some bank ever imposed (forced), so that those processes were NOT allowed (= got deferred) to run on days where CPU usage was already extremely high due to end-of-month processing. And by those restrictions they were able to keep their monthy invoices from their mainframe vendor(s) within the budgets they had planned for.  
> **username_3**: Seems to me that the execution patterns that are so well documented here are more like "Integration Execution Patterns", as they are not all continuous (like nightly builds #5)  

---

### Answer by username_4 on 2017-03-24. Score: 4

I would hesitate to describe your once per day model as CI/CD, it sounds more like the "nightly build" model.

It really depends on the nature of your work and processes. If things flow smoothly through building, testing, and preparation of an artifact for deployment and your development model / velocity isn't such that it would benefit from more frequent runs, I would say you have the spirit of CI/CD.

> **Comments:**
> **username_0**: Well, your answer is indeed another way to look at it, and is also why I wonder about what I mentioned in my question. Merci anyway!  

---

### Answer by username_3 on 2020-09-25. Score: 1

Periodicity will only come into effect if the overall integration and deployment processes take a long time to complete, which is more likely the actual problem. Said differently, in an environment where applications are built using lightweight architectures that are quickly scanned, built, deployed and tested, periodicity would cease to be relevant.

I would say that periodicity prevents a system from being truly continuous, so that is the way in which they are related. PI/PD


---

