如何使用 Pull 模型执行自动化部署
我们目前正在对我们的开发/质量保证服务器进行持续部署，并手动触发自动部署到我们的生产环境。目前我们正在使用 TeamCity/PowerShell/MsDeploy。我们现在需要部署到位于外部网络的服务器上，外部无法访问该目标服务器。相反，它必须“打电话回家”以获取更新，并且如果成功与否，可能会推迟结果。
我想我们可以编写一个服务，请求构建服务器上的特定 URL，并提供将用于部署的工件，将其下拉 - 然后启动构建脚本。
但是，我不完全确定我们将如何处理更新更新程序以及发生故障时的情况。有人对如何解决这个问题有任何建议吗？
We're currently doing continuous deployment to our dev/qa servers, and manually triggered automated deployment to our production boxes. Currently we're using TeamCity/PowerShell/MsDeploy. We now have a requirement to deploy to a server that sits on an external network, on which the target server cannot be accessed externally. Instead, it will have to "call home" for updates - and presumably then push the results back if it succeeds or not.
I'm thinking we could write a service that requests a particular URL on our build server with delivers the artifacts that would have been used for deployment, pull that down - and then fire off the build script.
However, I'm not entirely sure how we'd deal with updating the updater, and failures when they occur. Does anyone have any recommendations on how to approach this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来您需要一个发布存储库。构建服务器将文件推送到其中，每个部署作业从中提取文件。这将巧妙地解耦两个进程。
发布存储库可以像共享 NAS 一样简单，也可以是更复杂的东西，例如 Nexus 存储库管理器。
Sounds like you need a release repository. The build server pushes files into it and each deploy job pulls from it. This would neatly decouple the two processes.
A release repository could be as simple as a shared NAS, or something more sophisticated such as the Nexus repository manager.