所以假设有一个测试环境，其中每天从下午5点到（最大）下午6点执行所有必需的过程以进行重建受更改后的依赖关系（源，包含等）影响的所有可执行文件，以及与之相关的适当CI / CD进程。在下午5点之前和下午6点之后，不允许执行这些类型的过程（例如，确保相关环境的稳定性）。
是否执行此类周期性（= 5 pm之间）和每天下午6点）是否适合CI / CD？还是周期性与CI / CD无关？
#1 楼
我将CI和CD上下文分开，因为它们之一的周期性与另一种周期性的松散耦合。这主要是因为CI试图生产可用于交付/分发的软件版本，请参阅持续集成与持续交付/部署有何关系？
但并非所有CI执行都能成功。 CD的周期性充其量最多等于CI，但通常会更低。由不同的项目特定要求驱动。以下是CI执行模式的一些示例，可能还有其他示例：
每次更改集提交都会启动-建议这样做，因为它提供了最短的时间来识别导致回归的更改集，请参阅基于每次提交构建-持续交付。成本随提交率而变化。
每提交
N次（固定的提交次数）-交易罪魁祸首识别性能为＃1，成本略低（总体执行量更少） ）时间间隔由于预测的执行量而固定的成本：提交活动高峰期不会增加成本，一天的提交次数是另一次的仍将是相同的
如果在
T中提交了多个变更集，则罪犯的识别性能将下降＃1，在两次验证过程可靠性的度量之间没有提交任何变更集的情况下连续执行-这种执行的不同结果可能表明验证不可靠/>
只要有执行资源就启动-如果那是过程的瓶颈所在。可以根据与执行之间的时间间隔有关的提交模式来出现以上任何类别。这样可以最大化验证资源的投资回报率。
例如，在工作时间内以一种模式启动，而在夜间则以另一种模式启动-例如，以平衡计算资源的利用。
CI和CD之间的周期性不匹配的另一个可能原因是CI执行持续时间的可变性。例如，由您提到的受禁止的构建计划策略引起（另请参见如何实现冻结的测试环境？），或者由在性能明显不同的服务器类上执行的构建导致，因此持续时间长短不同。
即使成功执行配置项，并且所生产的软件版本符合条件并且可以进行部署，也不一定意味着它也将立即部署（甚至完全部署）。可能还有其他阻止它的标准或政策（例如，出于业务原因）。
评论
有趣的例子！知道其中哪一个最接近我的问题示例吗？好像是“ 3”，不是吗？
– Pierre.Vriens♦
17年3月19日在13:15
@ Pierre.Vriens我会在＃4旁边进行建模-只是在感兴趣的间隔内声明资源不可用。如果您将这些测试作为CI的一部分进行。如果它们是CD，则可以在sw / management系统中对其进行控制
–丹·科尼莱斯库（Dan Cornilescu）
17年3月19日在13:22
好吧，那将是我的第二选择（我怀疑）。它使我想起某些银行曾经强加（强制）的一些（昂贵的）大型机SCM进程，因此不允许这些进程（=推迟）在由于月末CPU使用率已经非常高的日子中运行处理。通过这些限制，他们能够将大型机供应商的月度发票保持在计划的预算范围内。
– Pierre.Vriens♦
17年3月19日在13:37
在我看来，这里记录如此丰富的执行模式更像是“集成执行模式”，因为它们并非都是连续的（如夜间构建＃5）
– Jimmyjambles
20 Sep 25'1:02
#2 楼
我会犹豫地将您的每天一次模型描述为CI / CD，这听起来更像是“每晚构建”模型。这实际上取决于您的工作和流程的性质。如果事情在构建，测试和准备要部署的工件过程中顺利进行，并且您的开发模型/速度不能使它受益于更频繁的运行，那么我想您会具有CI / CD的精神。 >
评论
好吧，您的回答确实是另一种看待它的方法，也是为什么我想知道我在问题中提到的内容。无论如何，谢谢！
– Pierre.Vriens♦
17 Mar 24 '17在15:28
#3 楼
只有在整体集成和部署过程需要很长时间才能完成（这很可能是实际问题）的情况下，周期性才会生效。换句话说，在使用快速扫描，构建，部署和测试的轻量级体系结构构建应用程序的环境中，周期性将不再重要。我要说周期性会阻止系统真正连续，因此是它们相关的方式。 PI / PD
评论
我认为没有关系，因为我们的CI / CD是由每次对存储库的推送触发的，因此产品团队应对推送时的影响负责。 （答案太短）@Tensibai有趣的一点，虽然它不是“没有关系”，但可能更像是“周期性的另一个例子是'按需'...”。
确实，这个问题听起来像是严格按照固定的时间表进行的，这就是我的评论的重点。您的变化还可以