delivery pipeline
下面这个是netflix的部署流程：
环境划分
dev/integration/test
dev
开发环境，服务不稳定，可能需要频繁重启之类的，一般每个开发者本地搭建开发环境。
integration
一般本地开发完，部署到integration环境，供其他合作的小伙伴联调集成，可能也需要服务重启之类的。
test
稳定版的integration环境，提供给测试环境其他服务用的，一般比较少重启。
小团队或项目，没必要区分这么多，排除开发者本地dev环境外，名义上的线下环境就一个，就是测试环境(integration/test).
staging(pre-production)
准生产环境，一般用于新功能的预上线，进行dogfood测试，没问题就可以部署生产环境。
staging环境越接近生产环境越好，除了服务器配置外，其他的最好跟生产的一样，比如连接的其他外部服务，连接的数据库等等。
另外，对于一些跟技术实现相关的，也需要注意一下，比如有状态的服务，如果staging是单实例的，可能没法测出问题来，需要弄成分布式的才能暴露问题，比如cas server回调client设置session，该session是本地的话，多实例的clint就会出现session不共享问题。
如果所有的新功能都是向下兼容的，那么可以用feature toggle，类似灰度部署一样，那么可以弱化staging环境，甚至可以不用staging环境。不过这个是理想的情况，软件开发里头的一个小改动，可能就影响到旧有功能了，无法隔离那么彻底。
关于staging环境，可以作为一个nginx上的upstream的一个backup，这样可以不浪费资源。不过有了docker之后，staging环境可以按需启用，新功能上之前，才部署，发布完可以撤掉staging环境，这样就不浪费资源了。
production
生产环境，要能够做到不停机发布，或者叫做不间断升级。
doc
