并没有真正运行传统的临

rmruhul

过部署预览，这基本上就成为了您的临时环境，不是吗？

莱斯利：确切地。我们时环境，因为我们真的相信，当我们点击合并按钮并在主应用程序中启动主分支的正式构建时，我们的部署预览本质上就会上线。因此，我喜欢我们可以依赖部署预览作为临时环境。我们真的相信它会与生产相匹配。我们正在使用所有生产变量、所有环境变量以及所有这些内容来构建它，这些内容都在部署预览中构建。所以，这很像是一种不用担心的情况。只要您的部署预览正常运行，您就知道该应用程序也将正常运行。

德鲁：我想，作为一个组织，如果您的部署预览与实际部署的内 电报号码数据 容不匹配，那么这就是 Netlify 想要解决的服务问题。所以，从这个角度来看，它实际上效果很好。因此，您已经查看了部署预览，一切看起来都很棒，PR 已合并。然后会发生什么？

莱斯利：因此，因为 Netlify 运行我们所有的持续部署，所以本质上我们已经将其全部连接起来，以便任何合并到我们的主分支中都会自动启动该应用程序的正式生产部署。因此，通常，如果您是合并自己 PR 的开发人员，您将弹出实际的...您必须确保仔细检查您的选项卡，因为如果您打开了应用程序的部署预览并且应用程序，你必须确保……你通常想要在真实的应用程序中进行操作。所以，你必须检查你的标签。但是，是的，在应用程序中，您通常会进入，您可以查看刚刚启动的合并的构建日志，所以这都是自动的。然后，一旦这些构建日志完成并且站点上线，您所要做的就是刷新浏览器窗口，您将看到刚刚部署的内容，应该在应用程序中更新。

德鲁：假设您在问题上线后发现了问题，那么您会做什么？



莱斯利：这是一个非常好的问题。也许在我在 Netlify 工作之前，我最喜欢使用 Netlify 的事情之一就是，这对我来说就像一点点魔法，因为 Netlify 已经融入了我们所说的回滚功能。因此，基本上 Netlify 上的每次部署……因为我们使用的是 Jamstack 架构，所以每次部署都是原子的。因此，这意味着您拥有在站点上进行的每种部署的完整历史记录，并且可以立即回滚到其中任何一种。因此，如果我们不小心部署了错误或出现了问题，我们通常要做的第一件事就是停止持续集成。因此，我们进入后，只需在 Netlify UI 中按下一个按钮，“停止自动发布”，它就会停止与 GitHub 的连接。因此，如果我的队友突然也合并他们的 PR，我们不会重新引入该错误，不会发生类似的情况。

莱斯利：因此，我们停止所有这些自动部署。然后我所要做的就是返回到我的部署列表并找到最后一个工作部署，再点击一个按钮，上面写着“发布这个”，然后它就会上线。所以，这样做的作用是减轻压力，让我们能够真正回去，查看代码，弄清楚到底发生了什么。有时，这意味着在主分支上执行 Git 恢复，并将主分支恢复到它需要的位置。有时这是一个热修复，或者你在一个分支上进行修复，你甚至不需要担心在 Git 中恢复。然后，当您准备返回时，请确保应用程序的部署预览中的一切正常，并且您只需重置所有内容即可。因此，一旦开始这些自动部署，您基本上就可以恢复正常工作了。

德鲁：所以，我在这里发现了一个问题。

莱斯利：呃哦。