客户那台 Windows Server 上跑着一个站点加两个服务。发一次版要做五件事：去 IIS 里建应用池和站点，选 .NET 版本、管道模式、端口和主机头；装服务、启起来；把公网 IP、端口、数据库连接串填进配置；执行数据库升级脚本；最后打个 zip 版本包留着。
顺序错一步，站点起不来，从头再走一遍。
现成的我先找过。WebDeploy 能推文件，IIS 的 PowerShell 模块能建应用池，还有一整套编排写进文件的发布平台，点一下编译部署通知全走完。方案都好，入口都是脚本或者编排配置：要用，先得明白应用池和管道模式是什么、参数挂哪一层、脚本在目标机上以什么身份跑。
要交付的那处不是开发做的。会点鼠标、会看日志，不愿意为了发一次版先学一门脚本。于是门槛不在功能上，在入口上：得反过来，做成不用教就会用的。
所以定了三条规矩，后面所有设计从这儿长出来。
一、使用者不是开发。要求他理解概念模型或者动手写点什么的，一律排掉。命令行、脚本化配置、YAML 编排都排掉，剩下图形界面：有按钮，看得见在干什么，走错能退。执行顺序也定死，自由编排等于允许他排错。
二、每多装一套软件就多一份学习成本。它跑在客户生产机上，不能要求对方先装运行时、先配部署平台。最后选 Windows Server 自带的 .NET Framework 4.6.1，第三方依赖跟着程序一起拷。交付物就两个：一个 exe，一个 xml。
（等价改写，名字换掉了）长这样：
<Configure>
<BasicWorkDirectory></BasicWorkDirectory>
<ApplicationTitle>IIS Deployer</ApplicationTitle>
</Configure>
三、出事得能退，所以不做直接覆盖。先停服，备份原文件，再覆盖，装好启起来。顺序写死，没有开关。
界面顶部五个模块按钮，中间一条固定链路：
目标在跑先停掉，站点不在就标成待安装；配置模板的占位符换成实际参数，先落临时版本目录；备份；覆盖，配置和模块搬进同一目录；安装启动，首次装完等一秒再启。动工作目录前站点一定停着——配置和模块最后都落进同一个目录，站点还在跑就覆盖，写进去的和正被请求的会撞，备份也不安稳。模块顺序是站点、脚本、服务，脚本目录空了跳过。
IIS 上的 .NET 版本、管道模式、端口主机头做成只读列表，只能勾，不能瞎填，改完点保存才生效。
规模不算大：十个工程，三百多个文件，去掉内嵌的压缩库，自写的一万九千行上下，配一份十七页带截图的图文手册。
它不是什么
只管 Windows Server 上单台机器。不管 Linux，不管容器编排，不管多环境流程，也不替代流水线。十几台机器要统一编排，去看流水线工具，这个帮不上。它是个拿管理员身份双击运行的桌面程序，服务枚举和 IIS 操作都要管理员权限，非管理员跑起来相关列表直接是空的。目标框架 4.6.1，只能跑 Windows。
编译需要 Visual Studio 2022，还原一次依赖包。运行就是把 exe 和那个 xml 拷到一个工作目录旁边，第一次启动锁在设置页，填一个有效的工作目录，其余模块才解锁。有个坑提前说：app.config 里那个资源扩展库的程序集绑定重定向不能少，少了运行时直接抛异常。
源码里每个取舍都能回溯到上面三条规矩，推导过程我写进了项目文档。
开发那几天的记录另有一组《部署器 · 开发手记》：说一个「等多久才算久」的事、备份做了，却退不回去、那笔代价算在谁头上。
本篇是《部署器 · 开源记》第 1 篇，合集在 部署器 · 开源记。