checkout阶段还是创建多个阶段，例如checkout scripts，checkout code，checkout something else？我应该如何决定将哪个逻辑放在单独的阶段？
还是阶段仅仅是管道可视化工具？
#1 楼
单一责任原理（SRP）Martin将责任定义为改变的原因，并得出结论
，一个类或模块应该有一个，并且只有一个理由是
更改（即重写）。例如，考虑一个
编译并打印报告的模块。想象一下，可以出于两个原因而更改这样的模块。首先，报告的内容可能会改变。其次，
报告的格式可以更改。这两件事因不同的原因而改变。一种实质性和一种化妆品。单一的
责任原则说，问题的这两个方面实际上是两个单独的责任，因此应该在单独的类或模块中。结合两个因不同原因而在不同时间发生变化的事物将是一个糟糕的设计。
使课程专注于单个关注点很重要的原因是
它使类更加强大。继续前面的
示例，如果报表编辑过程发生变化，则
如果打印代码属于同一类的一部分，则打印代码将被破坏的危险更大。 />
5-15行
函数通常应该简短，在5-15行之间是我个人的
“经验法则”用Java或C＃进行编码。出于以下原因，这是一个合适的尺寸：
它很容易在屏幕上显示而无需滚动
这是您可以握在头上的概念尺寸
它足够有意义，可以单独要求一个函数（作为独立的有意义的逻辑块）
如果函数少于5行，则表明您可能将代码分解太多了（这使得/
很难理解是否需要在函数之间导航。或者，或者
您忘记了特殊情况/错误处理！
个人视图
创建Jenkins舞台时，请牢记SRP。这意味着我为结帐，构建和发布创建了一个单独的阶段。如果一个阶段变得太大，即超过15行，那么我将创建一个脚本并在此阶段运行该脚本。好处之一是可读性强，可以在脚本上应用单元测试并且与CI无关，即也可以迁移到另一个CI。
示例
>
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building..'
}
}
stage('Test') {
steps {
echo 'Testing..'
}
}
stage('Deploy') {
steps {
echo 'Deploying....'
}
}
}
}
#2 楼
除了作为管道可视化工具外，各阶段还标识可能或多或少彼此独立执行的管道部分，可能在不同的工作人员上执行。不要低估选择正确的管道结构的重要性。可以在需要时重新执行阶段，例如在环境问题导致的故障情况下，而不必重新运行已经存在的阶段。完成的上游阶段。
阶段为管道分支提供了能力。例如，单个构建阶段可能会产生工件，与并行执行相比，多个下游测试阶段可以使用这些工件，从而缩短了总体管线执行时间。具有不同类型和大小。
可以有条件地执行阶段。例如，昂贵的集成测试阶段（冗长的和/或比构建阶段小的资源池）只能偶尔执行一次，而不是针对每个提交执行一次，或者只能在发行分支上执行，而不能在主开发分支上执行。
由于通常的目的是使管道由相应分支中的每个提交触发，所以管道的大小取决于管道的大小，即阶段数，持续时间和管道图的结构（它-不一定是线性的）-与以下内容可能存在复杂的关系：
触发管道的提交的速率和配置文件
资源池可用于支持流水线阶段的操作
分支机构的角色，被认为是强制性的质量水平与其在验证流水线结构上的映射之间的关联平衡（即哪些阶段的故障被视为阻塞，需要回退/相应的ch的回滚愤怒与那些可以解决的问题只是可以接受的）
在较小规模的项目中，为找出原因并修复管道执行过程中检测到的阻塞故障所需的额外工作量/资源，以完成（连续）集成/交付/部署过程。这些方面通常很简单，但规模较大，这些方面需要认真考虑，因为它们会对整个开发过程产生巨大影响。
我将以您的第一个问题为例：
如果您有十二个存储库，它们合计花费不到一分钟的时间进行检出/拉出操作，则可以使事情变得简单，然后将它们全部拉成一步就可以了。
如果您有数千个存储库，而这些存储库可能需要1小时以上的时间才能拉出，则可能应该仅在每个阶段拉入该阶段所需的内容。或者，也许在第一阶段将它们全部拉出，缓存它们，并在以后的阶段中重新使用该缓存，如果这样有助于避免重复冗长的提取。
在您特定的项目上下文中，任何有意义的事情。