在Azure DevOps中如何将exe文件作为发布环节部署到Windows服务器

方案1：内置自更新逻辑（最轻量，无额外工具依赖） #

• 给jobserver新增启动时版本校验逻辑：
  • 提前将打包好的新版本文件包上传到你已在使用的Azure存储Blob容器，配置私有访问权限，生成固定的带有效期SAS令牌即可
  • 在存储中单独维护一个version.json文件，记录最新版本号、对应文件包下载地址
  • jobserver启动时先拉取version.json和本地版本对比，检测到新版本后先判断是否有运行中任务，无任务则自动下载新版本文件覆盖本地目录，之后重启进程
• 额外在服务器添加一个Windows计划任务，配置业务低峰期自动重启一次jobserver，即可保证新版本最迟在低峰期自动完成更新，全程无需手动登录服务器操作
• 代码层面仅需新增几十行版本校验、文件下载、进程重启逻辑，对现有架构侵入极低

方案2：对接现有CI/CD流程推送部署（适配已有的自动化构建场景） #

• 你当前打包Web应用的CI流程（比如Azure DevOps、GitHub Actions等）可以新增一个jobserver构建步骤，构建完成后将输出包上传到统一文件存储
• 目标Windows服务器开启WinRM服务，配置权限仅允许你的CI服务器IP访问，提前写好固定的部署脚本存在服务器本地
• CI流程构建完成新版本后，通过WinRM远程触发服务器部署脚本执行：
  1. 调用jobserver内置的状态查询接口（或读取程序生成的运行状态文件）确认无运行中任务
  2. 停止jobserver进程（如果已经注册为Windows服务可直接执行Stop-Service jobserver命令）
  3. 下载新版本压缩包，解压覆盖本地程序目录
  4. 重启jobserver进程/服务
• 全程无需人工介入，可和现有Web应用的自动部署流程对齐，发布节奏完全统一

业界通用处理方式 #

如果后续有多台服务器需要管理，或者需要更规范的发布审核、灰度、回滚能力，通常会根据团队规模选择对应工具：

• 小型团队常用Ansible、SaltStack这类轻量配置管理工具，提前写好部署脚本，发布时一键执行即可批量处理多台服务器的更新
• 中大型团队会用企业级发布平台，内置进程状态检测、灰度发布、版本回滚、操作日志审计能力
• 所有方案的核心逻辑统一为：状态检测→停止进程→更新文件→重启进程，不需要为了炫技选择超出当前需求复杂度的架构

优化建议 #

• 建议将jobserver注册为Windows服务，可通过.NET自带的Microsoft.Extensions.Hosting.WindowsServices包快速实现，无需手动保持控制台窗口运行，进程崩溃后也能自动重启
• 提前给jobserver增加终止信号监听逻辑，收到停止信号后不再接收新任务，等待当前正在运行的任务全部执行完成后再退出，避免更新时中断业务
• 建议保留最近3个版本的程序文件备份，更新出现异常时可以快速回滚到上一个可用版本

内容的提问来源于stack exchange，提问作者Kjensen