问建立声明性管道或管道作为代码的正式标准是什么？

EN

管道作为代码(PaC)意味着CI/CD配置将存储在VCS中，而不是存储在CI/CD工具本身中，例如使用UI手动配置它。

有什么经验可以是什么“临界量”，这种投资是一个明确的回报，而不是一个过头？

假设过去几年中手动配置了100多个作业，并且希望将所有这些作业转换为PaC，那么这将意味着创建新特性的可用资源将减少，因此不可取，但如果要创建任务来解决这一问题，并将手动作业转换为PaC作业，那么从长远来看，这将是有益的。

优势PaC

不再有无休止的配置搜索

一个优点是不需要查看不同的地方，例如CI/CD工具，记录如何将CI/CD作业配置为与代码(即VCS )位于同一位置的相关内容。

不再有没完没了的不必要的调试

另一个优点是，有人不能轻易地中断CI/CD作业，就像使用UI配置它是可能的一样。例如，如果有人必须更改CI/CD，那么就必须更改VCS中的代码。由于可以跟踪每个代码更改，因此将立即清楚谁更改了管道，以及在管道中断时更改了什么。