· 部署很简单。简单到拷贝个 jar 包到一台机器上是上线了
　　· 部署也很复杂。如果30台服务器，我想先灰度发布 5 台机器，然后把东北区的流量都打到这5台机器上
　　· 部署也很昂贵。一个bug带到了线上可能带来几百万的损失。你还甭不信，有羊毛可以薅的bug比核辐射散布的还快。
　　对于一个发布人员来说期待的部署过程应该是怎样的呢？简单，要足够的简单；易回滚，要极简单的方式可以回滚。只要部署过程满足这两条，那么已经帮助发布人员很高兴了。再严重的bug只要可以很快的回滚，把带来问题的版本下线，很大程度上已经降低了公司的损失了。
　　部署是获取到可发布版本，然后将其部署到目标环境中（QA环境、线上环境）；如果出线问题，部署过程可以立刻回滚。
　　部署管理原则
　　· 部署过程须尽可能的简单、可靠
　　· 回滚过程要迅速、禁得起考验
　　· 部署和回滚过程都有相应的记录
　　· 线上系统的版本要有相应的监控程序
　　· 运维人员负责部署系统、对产品质量负责的人来实际部署
　　· 只有运维人员具有线上系统的访问权限
　　具体实践
　　· 部署过程须尽可能的简单、可靠、可重复
　　· 全量部署还是增量部署？顿时很多人以为这个问题争吵两个小时，像世界上好的语言是不是 php 一样，无论什么人都会参与进来。
　　· 一般的情况下，我觉得应该全量部署。当系统很小的时候，应该每次都全量部署，本来系统也很小；如果系统很大呢？我的建议把系统拆分成几个可以独立上线的部分，然后各个部分全量上线。
　　· 能全量上线的系统都有一个共同的特点是研发人员有更高的精神追求。我们总可以找到不能全量上线的理由，也许一开始到这个公司是增量上线，也许一开始刚来公司还可以挣扎一下，慢慢地也适应了不完美的增量上线。
　　如果采用增量上线，看似简单，其实有更大的风险。 增量上线的线上环境和预生产环境很难做到大程度的一致。一般情况下，采用增量上线都会有个处理各种异常、处理各种特殊情况、处理各种坑的增量上线脚本。可以说系统越大，这个脚本也越难维护，同时针对系统的版本，这个增量上线脚本也会有自己的版本。慢慢地上线脚本和系统也绑死在一起了，上线的过程也变得不那么的简单、可靠、可重复。与其维护一个烂得不行的增量上线脚本，不如痛下决心从系统架构、系统模块划分上开刀，把系统划分几个相对独立的部分，大程度的降低依赖，让上线活动变得轻松、简单的过程，而不是一个让人听了浑身紧张、如临大敌的事。