What's the relevance of periodicity in CI / CD processes?

Question

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?

Answer 1

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? 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. 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?) 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).

Answer 2

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.

Answer 3

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