PS：概要、背景、结语都是日常“装X”，可以跳过直接看自动发布
环境：阿里云SLB、阿里云ECS、IIS7.0、Jenkins、Spring.Net
概要
公司一个项目从无到有，不仅仅是系统从无到有的过程，也是项目管理流程、运维流程逐步完善的过程，今天主要说说运维方面的，从人肉运维到自动运维，我们搭建了运维平台来实现。运维平台在很多人理解应该是运维来做，不过就像前面文章说过，在很多公司，资源有限的情况下，研发往往是“万能”的，需要承担更多的责任，本文我们主要讲关于Asp.Net自动发布这一块。
背景
1、新进入一个公司，往往系统已经初具规模，已有成型的框架，但往往由于前期为了赶项目进度或者系统架构规划问题，随着系统功能的不断增加，一些运维方面的问题会越来越突显出来，如：配置管理混乱、站点特殊内容太多且无记录、发布纯人工操作等，发布风险很高，每次发布都提心吊胆，如临大敌；
2、作为一名想“偷懒”的程序员，自从走向管理岗，就开始为运维自动化的投入争取资源，公司的运维平台搭建基本都是自己做产品经理或者研发。目前我们实现了日志管理、调度管理、站点管理、ECS管理、负载均衡管理、配置管理（目前只是实现了配置分离，下一步会实现配置动态生效）、发布申请管理、自动发布管理、MQ消息队列管理，监控主要是用阿里云自带的，业务异常监控应该算目前比较缺失的一块，以及其他很多都需要完善，但对公司最紧急的基本都已经实现；
3、在当前Java风行，其他新兴语言慢慢崛起，并且微软自身也推出.Net Core的情况下，.Net的市场份额越来越小，很多公司都开始转Java，包括我目前所在的公司新系统也开始使用Java了。但就算转Java，以前的系统还是需要维护，对于公司来说花最小的代价达到优化的效果就行，转语言不是目的。对于程序员来说，掌握哪一种编程语言本身并不重要，更重要的是编程的思想、系统架构的思维，编程语言只是一种表现形式（作为一名.Net的老兵，最近在准备做Java的容器化，优化Java架构）。
自动发布
从我加入公司到现在，关于.Net的IIS站点发布大概经历了以下3个阶段：一、手工发布；二、半自动发布；三、系统自动发布；
一、手工发布
该阶段缺点：
1、运维人员需要记住相应的代码路径、解决方案、项目名称，站点新建没有标准，导致不同的站点有一些特殊的设置或操作，导致新入职的运维人员需要很长时间才能上手；
2、需要登录每台服务器修改配置，以及切换IIS站点路径，重启站点，且无法验证是否发布正常，发布工作量巨大，发布效率低，发布风险很高，把问题的发现抛给了用户，每次发布都提心吊胆；
3、没有统一的平台管理各类信息，导致大部分信息都记录在相应的研发或运维人员脑袋里，每次关键人员离职都是“大地震”，信息孤岛严重；
4、大部分工作都压在运维人员身上，且大多数时间都在做一些简单重复的工作，不利于运维人员自身的成长，难以留存人员。
二、半自动发布
该阶段优化内容：
1、制定IIS站点规范（如：配置与应用分离、增加发布成功测试页、规定特殊项的范围）；
2、运维平台实现IIS站点信息及配置管理（维护站点基本信息、配置信息、特殊项）；
3、运维平台实现阿里云SLB的管理（同步基本信息、添加/移除/刷新ECS状态）；
4、搭建Jenkins持续集成平台，实现预发布环境的站点发布（获取最新代码、生成打包、上传服务器、覆盖文件、重启站点）。
该阶段缺点：
1、投产站点发布还是需要运维人员登录到每台服务器里面进行操作，发布工作量大，且人工发布虽然有信息记录，但因为不同运维人员的能力不同，导致发布风险还是很高；
2、发布准备以及操作发布的时间都比较长，导致发布的前置时间比较长，不利于系统的快速迭代。
三、系统自动发布
该阶段优化内容：
1、利于IIS的FTP实现发布文件分发到IIS站点的各服务器，并复制到相应的站点目录下；
2、利于C#类库Microsoft.Web.Administration.dll，实现对IIS的站点管理，如：切换路径、站点重启等，相关代码见：IIS站点管理-IIS站点以管理员身份或指定用户运行；
3、实现IIS站点发布的批量操作，如：从SLB移除ECS、发布配置、发布站点、浏览测试页、从SLB添加ECS、直至成功标记为已发布。
自动发布相关截图：
1、创建发布申请：
2、发布操作页面
3、单个站点一键发布
4、批量发布组1同时移除组2
结语
.Net的份额确实是在逐年下降，微软自己开始主推.Net Core，不过对于公司已有的系统，有些并不一定要去花时间重构，能花最小的代价达到能接受的效果对公司才是最划算的；以上很多只是提供了思路，以及关键的实现，如果大家真的需要应用到自己公司的系统，还是需要结合自己公司的情况进行处理。