Deployment 部署到测试环境是持续集成的一部分吗？

我已经检查了很多源代码，但我仍然不清楚：部署到测试环境是CI的一部分，还是CI只是为了经常提交并保持主线无bug和集成？有人说，部署到目标环境是CI的一部分

---

< CI >和连续交付之间，我看不出有什么不同。

< P>持续集成可能或不需要你考虑部署到测试环境中的东西。CI的要点是在软件的某个版本上运行自动化测试，以确保版本i已准备好部署到下一步（QA、登台、生产或任何流程中的下一步）。因此，如果需要对软件进行测试，则部署软件，如果不需要，则不部署

<>始终有某种测试环境，因为自动化测试必须在某些计算机上运行，但是代码可能会或可能不会通过您所考虑的部署而到达。例如，如果应用程序使用解释语言，那么运行自动测试可能只需要将源代码复制到测试环境并运行脚本，而不是实际部署

---

自动化测试是否需要部署取决于应用程序具有何种类型的自动化测试。如果它只有单元测试，则不需要部署。如果它有完整的堆栈集成测试，根据集成测试框架的不同，可能需要部署，也可能不需要部署。例如，集成测试框架是Rails的一部分，它运行Rails服务器的一个特定于测试的版本，以便测试与之对话，因此这些测试不需要部署。另一方面，其他框架可能不提供这种支持，因此必须将应用程序部署到测试环境中，以使完整的堆栈集成测试能够运行。或者CI构建可能包括自动性能测试；这些当然需要针对部署到测试环境的应用程序运行。

谢谢。但什么是测试？自动的？大多数系统仍然需要测试人员进行手动验证（例如，带有GUI的系统，其中还需要检查可访问性、可用性等）。那么，连续交付有什么区别呢？是的，自动化测试。我在回答中说得更清楚了。应用程序可能有手动测试，但这不是CI的一部分。至于CD，如果您的应用程序在部署到生产环境之前必须运行手动测试，那么您不是在做CD。不过，您可以将CD刻录到生产环境中并在那里手动测试。此外，如果我们的应用程序（多层、DB、Java中间件和Flex UI）运行其单元和集成测试，它仍然是CI。然后它部署到我们的SIT环境中，让我们的测试人员执行一些测试-在Jenkins中手动触发部署-这是否仍然是CI的一部分？我读过的一些资料（如Pro:NET最佳实践）提到部署是CI中的一个步骤。这当然是您可以做的，我也做过，作为CI过程的一部分。但是，这不是CI的必要部分。如果你不介意的话，也许还有一个问题——为什么所有的源代码都在单元测试之后提到代码分析？我希望静态分析是检测问题的第一步，而不是在单元测试运行之后。