一千萬個為什麽

搜索

CI/CD過程中周期性的相關性是什麽?



(我認為)CI和CD的一部分是一再重復的過程(=它的 continuous )部分)。然而,在這種情況下,連續不斷(我認為)就像一條水一直在流動的河流。相反,它是每X秒,幾分鐘,幾小時等發生的事情。

因此,假設某些測試環境(例如從下午5點到下午6點)每天都執行所有必需的流程,以重建所有受更改的依賴關系(源,包括等)影響的可執行文件,並結合相應的CI/CD相關的流程。在下午5點之前和下午6點之後,這些過程都不允許執行(例如,以確保相關環境的穩定性)。

這種周期性(=每天下午5點到6點)是否適合CI/CD?還是說周期性與CI/CD無關?

轉載註明原文: CI/CD過程中周期性的相關性是什麽?

一共有 2 個回答:

我會分開CI和CD上下文,因為其中一個中的周期性與另一個中的周期性松散耦合。

這主要是因為CI試圖為交付/分發生成版本可用 ,請參閱持續集成與持續交付/部署有何關系? 但並非所有CI執行都成功。 CD的周期性至多與CI一樣,但通常會更低。

在CI中,周期性與期望的開發速度(可能是分支穩定性)緊密耦合,並且可以由不同的項目特定需求驅動。以下是CI執行模式的一些示例,可能還有其他一些示例:

  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.

CI和CD之間周期性不匹配的另一個可能原因是CI執行持續時間的可變性。例如,由您提到的禁止的構建計劃策略引起(另請參閱如何實現一個凍結的測試環境?)或者通過在具有明顯不同性能的服務器類上執行的構建,從而持續不同的時間量。

即使對於成功的CI執行,其中生成的軟件版本具有資格並可用於部署,也不一定意味著它也將立即部署(甚至可以部署)。可能有其他的標準或政策阻止它(例如商業原因)。

我會毫不猶豫地將你每天一次的模型描述為CI/CD,這聽起來更像是“夜間建造”模型。

這真的取決於你的工作和流程的性質。如果通過構建,測試和準備部署工件以及您的開發模型/速度並非如此,以至於它可以從更頻繁的運行中受益,那麽我會說您擁有CI/CD的精神。