开始折腾：解决更新分发这个老大难问题
我这人做东西，最大的毛病就是前端代码写得挺漂亮，但一到后台分发，就跟个新手一样，乱七八糟。我那个“诺艾尔”小工具，一开始是给几个朋友用的，代码迭代得特别快。每次更新，我都得把新的安装包和补丁包，打包成一个压缩文件，然后上传到某个网盘或者直接用微信发过去。大家下载倒是挺方便，但问题是，网盘链接有效期一过，或者微信文件缓存清了，历史版本就彻底找不到了。
我被朋友们抱怨了好多次，说这个系统太不靠谱了，每次换电脑，安装包都得管我要。我心里就下定决心，必须彻底搞定这个更新地址和安装包的分发问题。我要的不只是一个能放文件的地儿，而是要一个能永久且稳定，并且能自动推送版本信息的地方。
我一开始想得挺美，是不是用现成的第三方服务就行了？我先是试了某家国外的免费对象存储，结果发现国内访问速度慢得像蜗牛，而且免费的流量限制特别死。稍微有一点点下载量，马上就弹窗警告，要我升级套餐，这不是扯淡嘛我又换了一个国内的云存储，倒是快了，但是每次文件上传后，生成的外链地址都有一个固定的有效期，三个月一到，链接就自动失效了。我总不能每三个月就手动跑去改一次配置文件？那不符合我“诺艾尔会努力”的口号。
实践过程：从零拉起一个私人分发站
既然现成的方案都不行，我就决定自己动手，丰衣足食。我前两年手里还闲置着一台最低配的云服务器，平时就跑个博客，完全是大材小用。我决定把这个机器利用起来，专门用来做“诺艾尔”的更新和安装包托管。
我第一步就是把服务器环境清理了一遍。我以前上面跑的是一个老旧的Java应用，占资源还慢。我直接把那个应用卸载了，然后装了一个轻量级的网页服务软件。这个软件的好处就是，配置起来简单，专门用来处理静态文件，也就是我的安装包和更新说明文件，速度飞快。
我的部署过程主要走了这么几步：
-
分区规划： 我在服务器的根目录下创建了两个重要的文件夹。一个是
/install/，专门放完整的安装包，这是给新用户准备的。另一个是/update/，这里面扔了一个特别简单的版本信息文件，就是一个文本文件，里面写着当前最新的版本号、文件大小和下载地址。 - 配置网页服务器： 我把网页服务器设定让它能直接通过我的域名访问到这两个文件夹。并且设置了一个很重要的东西，就是文件的MIME类型。我得确保下载器能把我的安装包认作是一个可执行文件，而不是一个普通的网页。这个地方我刚开始没注意，导致大家下载下来的文件，后缀名都乱七八糟，打不开，折腾了我半天才找到原因。
-
自动化上传脚本： 我最怕的就是手动操作。所以我就写了一个超级简单的小程序，这个小程序只做一件事：当我本地打包好新的安装包后，我双击运行它，它就自动连接上我的服务器，把新的安装包传到
/install/里，并且自动更新/update/里的那个版本信息文件。这个脚本一开始各种权限报错，服务器老是拒绝我的连接，我调了一整个晚上，终于在凌晨三点，看着它成功跑完了全程，那叫一个踏实。
为什么我非要自己折腾这个？
可能有人会说，一个私人的小工具，费这么大力气搞一个专业的更新分发系统，是不是有点小题大做了？我为啥要死磕这个？
我这人以前就是个乙方，做项目的时候，客户对我的代码质量从来没啥意见，但是对我的交付流程，那是意见大得去了。以前我就是习惯性地把最终成果扔到一个临时链接里，然后通知客户。结果？客户的采购部门、测试部门和最终使用部门，三方互相推诿，总有人说没收到文件，或者链接过期了，来来回回耽误项目进度。
有一次，我给一个老客户交付了一个重要的系统更新，当时我人正在外地，没带电脑。客户打电话来说安装包打不开了，问我新的更新地址在哪里。我当时脑子一片空白，只能让他先等着。结果就是那次意外，让客户对我的信任度大幅下降，后来那个项目直接转给了别的公司。我当时就悟了，技术再牛，交付渠道不专业，在别人眼里就是不靠谱。
我这回拉起来的这个“诺艾尔会努力的”更新地址，与其说是一个工具的分发渠道，不如说是我给自己立的一个规矩：做事要靠谱，从头到尾都得是专业的。现在这个系统已经稳定运行了快一年了，每次更新，我只需要跑一遍那个自动化脚本，新的安装包和地址就立刻上线了。朋友们再也没问过我要安装包的链接，因为他们知道，那个固定的更新地址，永远都在那里等着他们。这种稳当劲儿，用再多钱都买不来。