5

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?

  • 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 Mar 18 '17 at 19:05
  • @Tensibai interesting point, though instead of "no relation" maybe it's rather like "another example of periodicity is 'on demand' ...". – Pierre.Vriens Mar 18 '17 at 19:20
  • Indeed, the question sounded heavily oriented on fixed schedule which was the point of my comment. Your variation is ok – Tensibai Mar 18 '17 at 19:27
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? 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).

  • Interesting examples! Any idea which one of them is closest to the example in my question? Seems to it is "3.", no? – Pierre.Vriens Mar 19 '17 at 13:15
  • @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 Mar 19 '17 at 13:22
  • 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 Mar 19 '17 at 13:37
3

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.

  • 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 Mar 24 '17 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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