本文内容比较杂，属于草稿材料，后续会拆到其它篇内
背景
在IT行业早期的时候，普遍是软件公司针对各行业的公司进行针对性管理业务软件开发，或开发某类型的行业软件，如ERP，OA, CRM等为代表的软件。
这种场景下，软件一般都迭代得比较慢，因为传统行业在过去几十年和上百年历史中发展得已经很成熟了，所以软件开发更多的是偏辅助企业管理用途的应用。
产生的现象就是，一个软件，往往需要数年时间开发和测试，完备之后才进行交付，交付之后几年或十几年都不会大改什么功能，最多就是小修小补一些bug啥的。
于是整个IT行业中，开发人员和运维人员的比例差异极大，维护人员占主流。
对运维人员的要求一般就是能把某个软件玩转就行了，也不需要什么开发能力，最多就是写个脚本，补补数据啥的。各种论坛流行的也是如什么破解版，密钥, 装机, 等等。
可是随着互联网的爆发，很多传统行业也跟随着做出了改变；
软件开发的重心由早期的企业内部软件，变更为针对消费者和用户的在线服务类软件了。
服务质量差异
传统企业业务系统和在线服务类应用的要求完全不一样。
比如ERP系统，慢点无所谓，压榨一下员工要求加加班就行了；
故障率高点也没关系，厂家第二天或第三天再上门服务也来得及。
但是在线服务类应用要求可不是一般的高。
用户打开页面超过2-3秒都没有出内容，那就该去别家看看了；
用户刷新页面几次都打不开，那估计以后也没这个用户了；
很多的异常都可以影响全量用户，
例如数据库故障丢了数据，严重点的话某些依赖度高的公司也就该倒闭了。
变更频率差异
传统行业和企业软件，几年或十几年都不会有啥功能变化，企业几乎都不会招聘开发人员。
但互联网时代的在线服务可就不一样了，
别家三天一个活动，五天一个新玩法，半个月一个爆款。\
你跟不跟？
不跟的话，新老用户都去围绕着竞争对手转了。
跟的话，怎么跟？
传统的依赖第三方软件厂商的模式肯定是跟不上的，别人活动都结束半年了，你这可能还没有完成立项或招标。
特别是攒大招这种行为，很可能项目一半都没有完成，市场已经彻底都没了。
所以只能是自己维护开发团队，极限压缩开发周期，小步快走，逐步迭代模式；
通常采用的办法
- 快速推出原型进行市场验证，再逐步迭代完善；
- 将多个大的功能或需求进行细化拆分为一个个小目标；
- 缩短测试周期，快速上线；
- 每轮只上独立的一个小功能和需求，保证持续的市场热度。
最理想的情况自然是将：产生需求->实现->上线， 这三个阶段压缩到秒级别去啦！
但是目前多数情况肯定是达不到的；
好，既然秒级实现不了，那么放宽一点要求，分钟级别，小时级别，天级别呢?
反正肯定不能再是“月”和“年”了吧。
时间都去哪了
软件开发模式压缩到极致也至少需要这四个阶段: 需求->开发->测试->上线;
所以需要针对各阶段分别优化。
目标: 尽量加快上线速度。
需求阶段优化: 这个主要是企业和管理，以及业务方上进行完善了；
而开发测试和上线，方法就比较多了。
开发人员编码加速
某些小系统或组件在开发时，只有一个核心开发人员，通常这位开发人员本地电脑就有完整的环境。
本地就可以完成开发、调试、打包整个流程，然后交付给测试或运维人员一个jar包或二进制文件等。
测试人员再测试环境进行测试，运维人员再拿到生产环境进行部署。
看起来好像没有啥问题，但是如果涉及到多位开发人员时就比较麻烦了；
- 源码要上仓库吧
- 基础组件如 数据库、mq、redis这些没必要每个研发电脑本地一套吧；
- 开发人员本地的环境大多都是不一致的，不同人打出的包，可能完全不一样；
ps 我之前某个项目就这样，A同事打包后只有10M左右，我觉得明显不对吧，于是去找B同事，他给了我一个80M的jar包，我放到生产环境一启动就报错缺少东西，来回走好几遍才补完整依赖，上线成功。
所以多位研发这边也还是需要一个统一的开发环境，统一的依赖库。
例如: git, mysql, redis, mq, mvn私服, jenkins
测试环境加速
目前主推自动化测试，除了新增的功能点，可能需要人员手工去点一下，历史的功能点，能自动化的尽量自动化吧。
测试环境分类
- 开发环境和测试环境混合的场景。
有些小点的项目可以不分开，开发人员直接使用测试环境进行开发，确定版本后，测试人员立即测试； - 独立的测试环境场景。
有利于隔离性，且开发和测试人员可以并行工作，即开发 v0.3, 测试 v0.2, 生产 v0.1, 更有利于快速推进； - 灰度环境。
即临时性的小生产环境，用于上线前引入少量业务流量进行验证场景。
生产环境部署加速
常见方法
- 并行部署，如 ansible
- 流量切换
- 容器化
其它
TODO: 专题素材
