DevProcess
理想化的开发流程是准备五套环境：
- Local（本地开发环境）
- Dev（自动测试环境）
- Test（测试环境）
- PreOnline（预上线环境）
- Online（线上环境）
其中Local环境一套资源池，Dev和Test共用一套资源池，PreOnline和Online共用一套资源池。资源池包括Redis、Mysql、Memcached、Zookeeper、Kafka等。
本地开发环境需保证快速开发，支持开发环境快速搭建，本地开发的时候最好是专门找一台机器（或虚拟机）专门跑项目的各种依赖服务。开发者只关注本项目开发就可以了。 理想的情况是新人入职，从Git pull下来项目，直接导入IDE就可以开发，不需要任何额外的配置（git配置、maven setting.xml等基本配置是必须的）。 Git分支使用开发分支。
代码提交提交之后，持续集成工具会自动的跑单元测试、编译、打包，并启动服务进行集成测试，如果测试都跑通过，CI自动发布到测试环境。 根据项目需要决定集成测试之后是否是要停掉dev环境上的服务。
Test环境需要提供给客户端开发、测试团队一个稳定服务，而开发人员偶尔提交的代码可能会导致起不来，这是为什么需要Dev环境的原因。 Dev环境和Test环境共用一套资源池是为了保证Dev环境需要保证和Test环境的配置一直，才能保证发布到Test环境的包没有问题。 Test环境测试通过之后，需要把git分支合并到主分支，并打tag。并需要保证发布到maven私服的jar包profile必须是prod！
预上线环境是为了保证在测试阶段测试通过的逻辑也需要在线上环境保证运行通过，虽然理想情况下Test环境测试通过的代码在线上环境也没问题，但是线上环境和测试环境有一些区别导致运行结果的不一致：
- 分库分表：测试环境可能只会分一个库，而线上环境要复杂的多
- 流量：测试环境流量非常小，一些问题可能在流量小的时候无法暴露
- 发布频率：由于线上环境程序会跑好长时间，一些问题可能在短时间内无法暴露。
- 代码区分环境分支：代码里可能有区分环境的逻辑分支，需要保证线上环境也测试通过
线上环境需要保证提供稳定的服务，而且发布之后会直接影响用户，所以在上线之前一定要做好充分的测试，并在用户请求量小的时候上线。 灰度发布：由于线上环境的复杂性，就算全部测试用例跑通过，也可能会出现各种问题，这时候就需要引入恢复发布，灰度发布一般有三种模型：
- 随机负载均衡：这种情况灰度发布会导致用户多次请求一会儿会访问最新的程序，一会儿会访问老的程序，在接口比较简单的情况下可以使用
- 根据用户Hash负载均衡：不会出现上面的问题，但是可能会导致机器负载不一致。
- Zookeeper自动配置：可以配置固定用户、IP、用户段、IP段等访问固定的机器，支持动态配置，比较灵活。
有的时候需要多个项目同时开发，有两种方案：
- dev环境通过之后等待merge到主分支（或预发布分支），然后再发布到Test环境，缺点是需要人工干预
- 搭建多套Test环境，各个分支独立测试，测完之后一并合并到主分支然后上线，缺点是合并后可能需要再测试一遍。
开发流程没有完美的，只有最适合的，我们的目标是快速的持续交付稳定无bug的程序，并对用户影响尽量小。以上是笔者总结的一些经验，如有不妥之处，敬请告知。