如何使用GitLab将Web应用部署到Windows Server

以下两个方案都能满足演示环境部署需求，可根据自身熟悉程度选择：

方案1：GitLab 原生工具部署（优先匹配官方工具选型要求） #

全程使用GitLab官方组件，不需要额外引入第三方部署工具，配置门槛低：

• 前置准备
  • 在目标Windows Server上安装GitLab Runner，注册到对应项目的GitLab CI中，执行器选择shell，给Runner分配本地管理员权限（满足启停服务、操作文件目录的权限要求即可）
  • 给该Runner打上自定义标签比如windows-demo，CI任务指定标签后就只会调度到这台演示机执行，不会占用其他构建节点资源，注意不要把这个Runner设为全局共享Runner，避免其他项目任务抢占演示机资源
• CI流水线配置逻辑
  单独拆分deploy阶段，放在构建、测试阶段之后，建议配置为仅当主干分支推送版本标签时触发，避免日常提交误更新演示环境。三个核心步骤直接写在部署Job的脚本里即可：
  1. 停止旧版本应用：根据应用的运行形式写对应PowerShell命令，IIS托管的应用执行Stop-Website -Name "你的演示站点名称"，独立EXE运行的应用执行Stop-Process -Name "你的应用进程名" -Force -ErrorAction SilentlyContinue，加错误忽略参数避免首次部署无旧进程时流程中断
  2. 同步新版本产物：提前在构建Job中通过artifacts配置把构建输出的应用产物归档，部署阶段直接将产物复制到服务器的应用部署目录即可，不需要额外搭建FTP/SSH传输服务，参考命令：

     # 清空旧版本文件
     Remove-Item "C:\apps\demo-web\*" -Recurse -Force -ErrorAction SilentlyContinue
     # 复制新构建产物到部署目录
     Copy-Item -Path "$CI_PROJECT_DIR\构建输出目录\*" -Destination "C:\apps\demo-web\" -Recurse -Force
     

  3. 启动新版本应用：对应停止服务的逻辑反向操作即可，IIS站点执行Start-Website -Name "你的演示站点名称"，独立EXE执行Start-Process -FilePath "C:\apps\demo-web\你的启动exe" -WindowStyle Hidden，启动后可以加一行端口校验命令Test-NetConnection -ComputerName localhost -Port 应用服务端口，校验失败直接让CI任务报错，方便快速定位问题

方案2：Docker 部署方案（环境一致性好，后续维护成本低） #

如果不想在服务器上提前配置应用运行时（比如JDK、Node、.NET环境），可以选容器化方案：

• 前置准备
  确保Windows Server版本为2016及以上（支持Windows容器），可以直接在服务器上装执行器为docker的GitLab Runner，也可以在现有构建节点完成镜像构建后，通过简单脚本触发服务器拉取新镜像重启服务
• CI流水线配置逻辑
  1. 构建阶段基于Windows基础镜像给应用写Dockerfile，构建完成后将镜像推送到GitLab内置的容器镜像仓库，用提交短哈希作为镜像标签方便版本追溯
  2. 部署阶段三个步骤通过Docker命令即可完成，不需要额外配置进程/站点启停逻辑：

     # 停止并删除旧版本容器
     docker stop demo-web; docker rm demo-web -f
     # 拉取对应版本的新镜像
     docker pull 你的GitLab镜像仓库地址/demo-web:$CI_COMMIT_SHORT_SHA
     # 启动新版本容器，映射好服务端口
     docker run -d -p 对外访问端口:容器内服务端口 --name demo-web 你的GitLab镜像仓库地址/demo-web:$CI_COMMIT_SHORT_SHA
     

这个方案不需要在服务器上预装任何应用运行时依赖，所有环境都打包在镜像里，后续如果要迁移演示服务器，只要装个Docker就能直接跑，不会出现环境不一致的问题。

小提示：因为是演示环境，不需要配置蓝绿发布、灰度放量这类复杂能力，以上任意方案从零开始配置的耗时基本都在30分钟以内，足够满足使用需求。

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