我们应该在 CI 生命周期中何时进行覆盖率静态分析（无构建、无构建捕获，因为我们不使用编译语言）？我们有测试、构建、部署等阶段。不同方法的优缺点是什么？
这适用于部署到 kubernetes 上的 django 应用程序。
test 阶段涉及测试 django 端点。
build 阶段涉及构建一个 docker 容器。
deploy 阶段涉及推出最近构建的 docker 映像。
如果我要创建一个新阶段，应该什么时候完成？执行此操作时遵循任何约定吗？
【问题讨论】：
标签： django continuous-integration continuous-deployment coverity
决定在构建管道中放置某些检查的位置取决于您希望从这些检查中获得什么。
构建管道首先应该为您提供快速反馈。您想尽快知道是否有任何重要的事情会阻止您的构建投入生产。这就是为什么您倾向于将快速运行的检查转移到管道的早期阶段。通过这种方式，您可以快速检查是否值得进入管道中更慢、更繁琐的步骤。
如果您的静态代码分析检测到问题，您是否希望构建失败？如果是这样，这可能是提前将此步骤纳入您的管道的指标。
您的静态代码分析需要多长时间来分析您的代码库？如果只是几秒钟的事情，您可以将其放入管道的早期阶段，而无需过多考虑。如果构建需要大量时间（可能是几十秒甚至几分钟），这表明您应该将其移至稍后阶段，以便可以先运行其他更快的检查。
您可以但不必将静态代码分析放入现有（test、build 和 deploy）阶段之一，但没有人阻止您为此在管道中创建专用阶段（verification 可能吗？）。
没有理由对此持教条主义。尝试并看看什么对你有用是很有价值的。强调快速反馈是一个很好的经验法则，它可以提出一个构建管道，它不需要您观看构建 20 分钟，只是看到您在第 24 行出现了缩进错误.
【讨论】：