“下班了，走不走？” “你先走吧，今晚上线。。。” “。。。。”
上线又是上线，上线这个大问题，几乎每个程序员每天都会执行很多次的机械操作。测试环境、仿真环境，预上线环境，生产环境；互联网思维的“快速迭代”，“小步快跑”；强调用户体验 的快速用户反馈响应 等这些大环境，再到开发时间仓促、开发人员的配合情况、测试的严格程度、线下环境线上环境的差异等等因素，小到页面文字的修改，大到性能问题、架构问题的大幅调整，就算是生产环境，都不得不无时无刻面对着强大的上线压力。
那么我们是怎么上线呢？
1，借助VS的发布把网站发布到本地；
2，从tfs里查看，从上次发布之后开发人员签入的历史记录，识别出需要更新哪个dll、哪个页面或view、样式、脚本等，按网站的目录结构制作一个上线的增量更新包；
3，如果有配置修改，复制一个线上的web.config到更新包，再加上或修改相应的配置；如果有文件压缩任务的，执行压缩；等等的修改完善增量包使之符合上线要求；
4，找一个合适的时机覆盖线上网站目录，如果有多台实际服务器，就执行多次；或者你们有跳板机，并且有相应的文件的同步机制；再或者先更新预上线环境，测试之后，线上直接切换站点到预上线。
好，一次上线完成了。这只是我正在经历并且一直在重复的上线流程，当然其中会经过多个环境的测试不说了，熟练之后整个上线过程可以在10几分钟内完成。并且我要告诉你的是，所有的线上服务器，我们都是上一台测试一台没有大问题之后再上另一台。可以说这个过程虽然麻烦点，但基本做到无痛更新，也算是稳定高效的，^_^ 。。。
当然上面说的最见的小幅更新或打补丁或增加新功能，有时候你会碰到破坏式的更新，需要数据库的变动并且修改不能兼容现在的生产环境，那么恭喜你，发个网站公告，高挂休战牌，找个半夜，速度更新吧，而网站更新流程基本和上边差不多。
有什么不妥吗
如果以目的为衡量，流程完全可以啊；但是，整个流程各个步骤全手动，全手动，全手动啊，最不靠谱的就是手动，常言说：常在河边走，哪有不手抖；手抖把线上数据给全删了，手抖覆盖错网站目录了。。。；怎么避免手抖啊，健身。。。来罐红牛。。。C，怎么办，好，用工具替代。
如何改进
1，静态文件的处理自动化
专职做前端的都会了解grunt或gulp，这些工具把前端发布的压缩、合并、模糊等全都以代码的方式做到流程化、自动化，看得让VS开发者着急啊。
令人欣喜的是，VS2015已经做了足够工作，加入了任务管理器，让我们在发布过程中方便的加入自己的逻辑；并且可以集成grunt、gulp、npm、bower等让我们以更现代的方式管理前端依赖、流程化、自动化；typescript、less等也有了更完美的使用方式。不得不说，vs2015在开放性这块进步太大了，强力推荐有条件的速度升级啊。
15之前如何完成静态文件的自动化呢？这里推荐一个插件：Web Essentials，安装完成后，在相应文件夹上菜单上选择相应操作执行一次压缩操作生成压缩文件，之后每次编辑文件，保存时就会自动执行压缩操作，你所要做的就是加一个配置：让生产环境使用压缩或合并之后的文件。
说到配置，如何避免频繁的配置修改呢？避免上线时的手工修改配置呢？
2，Web.config 转换
你是否对网站web.config下边的Web.Debug.config 和 Web.Release.config 产生过兴趣？他们是什么作用，嗯，我知道，无非就是debug发布模式下，会使用Web.Debug.config，相应的release发布模式下使用Web.Release.config。哈哈，恭喜你，答错了。。。
我们知道web.config是一个XML格式的配置文件，而web.xxx.config也是一个XML文件，它不是配置，而是对web.config的配置的转换：它定义的内容都是对web.config里配置节点的执行一个匹配和转换的操作。
例如：我们在web.config中定义静态文件后缀的配置：
| <add key="StaticFileType" value="" /> |
配置为空，这样表示使用原始文件。
而在web.release.config中：
| <add key="StaticFileType" value=".min" xdt:Locator="Match(key)" xdt:Transform="Replace" /> |
这样，我们在release模式下发布的网站，配置的值就会是 .min ,这样就是我们在生产环境下使用的静态文件的后缀。
推而广之，我们通过这种方式，我们在开发时就做好 web.xxx.config，保证release模式下发布出来的配置一定是不经过任何人为修改就可以直接覆盖线上环境的的配置文件。
这样，我们就能保证release发布出来的网站包，直接就是可以覆盖线上目录的网站包。
但是我们怎么可能每次都全量更新啊，对我们要出增量包。
3，自动打出增量更新包
上文描述的手动打增量更新包的方式，费时费力又容易出错，其实这个步骤是最机械重复又没有意义的操作，但是我们就是重复并且还会一直重复，哎。怎么自动打增量包呢？确切的说，我也没有方法。
有毅力的同学可以研究下，但是想通过另外一个方式解决，大概思路就是：用新的网站发布包和上一次的网站发布包比较，把新包里与旧包里不一样的文件按原有目录形成一个增量更新包。
通过一痛猛找，发现在现有的工具：能做到两个文件夹的比较，并且列出不一致的文件，但是没有找到能把不一样的文件自动按原有目录结构形成增量包的功能。怎么办，自己动手，程序员做这个小工具还不简单吗，最近了解了下window下的shell，powershell，就写一个小脚本。
虽说是用来打增量包，其实可以用来比较任意两个文件夹，然后按原来的目录结构开成一个差异包。有兴趣的可以使用，修改最下边的几个配置参数就能使用，当然并没有严格测试，欢迎踊跃测试，提意见，提bug，提交代码。
说到powershell，写惯了正规的C#代码，写ps代码，简直是受虐，几乎要颠覆所有对语言的正常理解。但好在灵活，并且功能强大（能使用.net的所有功能）
好，增量包也出来了，该覆盖了，接下来
4，减少应用程序域重启次数
我们知道对配置和dll的任何变动，都会造成应用程序域的重启，而在一个覆盖过程中可能会造成应用程序域重启数次，这对用户来说是可能是短暂的响应延迟，而对服务器来说是连接数的快速上升，因此我们应该尽量减少避免应用程序的重启次数。
| <httpRuntime waitChangeNotification="5" maxWaitChangeNotification="20"/> |
就是这两个配置项，如上的配置：只要我们两个引起重启的文件变动间隔在5秒内，并且整个覆盖过程在20秒内完成，我们可以做到一次覆盖过程中只造成应用程序域的一次重启。
5，文件的同步与分发
这里就说到了如何把增量包发布到生产环境了。
1，切站点，可能是最理想的上线方式了。但是切站点，实施的方式就是把域名强制绑定到另外一个站点上去提供服务，因为一个域名只能绑定的同一个服务器的一个站点上，绑定过程中会造成原来站点的停止运行，在这个时间段进来的用户就受不到正常的服务了。而直接覆盖站点的方式造成的应用程序重启，只会造成短暂的延迟，理想情况下不会失去服务能力。
2，自己的同步机制，也就是在把增量覆盖到一个指定的文件里，自己的工具，会监测到哪些文件变动，然后同步到实际服务器上。这种方式安全快捷，但是缺点是几点服务器会同时进行和重启的进程，影响较大。如果发生有文件错误或同步过程出错，整个网站全部无法访问。
3，手动覆盖，可以自己控制节奏，但是缺点就是怕手抖，一个大意覆盖错了网站目录，影响太大了。
各有优缺点，提供另外一种方法：利用文件同步工具，推荐一个开源工具FreeFileSync，在跳板机上或者一台服务器上，定义需要同步源和目标，定义同步策略，保存设置以下次使用。灵活的控制是全部一次更新，还是更新其中任意一个，做好设置之后每次只是点点鼠标的问题了。
更为厉害的是有了这个工具，其实完全可以不需要上边打增量包的过程，工具会比较左右文件，然后只对不同的文件进行创建或复制。
当然左边文件也可以不是全部的网站源码，可以只是我们上边打出的增量包，这样整个同步过程就不用再去比较其它不需要更新的文件，让我们整个同步过程会更加快速，减少应用程序重启的机率和次数。
好了，整个过程就是这样的。利用.net自身的一些小特性和一些开源工具，或者自己的小代码，把整个过程简化为一次配置，以后基本自动化的地步，还是很不错的。配置完成之后的更新流程就变成了：VS发布，打增量包或者不打，上传到服务器一个文件夹，打开同步工具，选择这个站点的同步设置，执行全部同步或单个逐步执行。整个过程再也不怕手抖了，^_^