部署环境与分支版本管理

环境

第一个问题，究竟需要几套环境？按使用场景，我们可能会有以下环境；也依据实际用量和资源情况增减
1. 开发环境 - dev
2. 测试环境 - qa
3. 预生产环境 -stg
4. 生产环境 - pro
5. 演示环境 - demo
6. 沙箱环境 - sandbox

开发环境qa

当项目越来越复杂时，个人电脑上往往无法满足搭建整套软件环境的需求，或者即便可以搭建起来，但对运行性能很高，使得开发电脑变的很慢。

开发环境上除了会跑常见的数据库、缓存、消息队列等；同时会跑其他关联服务，比如用户服务、邮件服务、实名认证服务等

测试环境qa

由于需要进行压测、安全测试等，所以环境配置尽可能和生产环境一致；通常对应到敏捷迭代中的sprint

预生产环境stg

主要用于生产环境前的验证，比如业务UAT。对应于敏捷迭代中的release（并不是每个sprint都需要变成一个release，也不一定是每个release都包含sprint）。比如
1. 一个完整的端到端功能（或者是想上线一个大的版本其中包含多个关联功能）需要多个sprint才能够完成，能力上无法拆分成更细的mvp（或者是商业上决定多个版本一起发布）；这时候可能会出现每个sprint都做测试，但发布的包是积累在stg环境上的，需要做关联的测试（虽然与敏捷的概念有点相悖）
2. 很多时候并没有hotfix的专门环境，预生产环境有时候也会被用来做hotfix环境

生产环境pro

就是线上环境，因为很多时候前面几个环境并不能完全和生产环境一致，比如数据量、用户量、外部依赖服务等，因此因尽可能多的考虑日志和监控运维

演示环境demo

做2B服务时，商务、售前等角色往往需要对外做演示；一方面是完整的业务数据，针对不同演示的优化（比如logo\数据\甚至功能或功能mock）。有些重销售的公司会有多个演示环境。

沙箱环境sandbox

常常用于saas中的开放api调用；潜客自己的diy等。为了保证沙箱环境的稳定，常常会采取以下策略
1. 限制权限 - 避免对核心数据的修改
2. 拆分 - 为不同客户生成不同的环境
3. 阶段重置 - 比如每天夜里重置沙箱数据
4. 线下联系 - 对高意向或大客户，可能会单独部署沙箱测试环境

分支与版本管理

分支常常会与环境相对应。具体的版本会依据环境更加复杂：
1. 区分版本所描述的对象
1. 代码版本
2. 产品版本
3. 工件版本 （比如镜像；也有时和交付物放一块）
4. 交付物版本 （比如文档、安装包等）
2. 版本号
1. 代码版本通常是代码的版本控制系统
2. 其他版本，通常会更具类型、环境定义一套"tag"规则；"tag"针对"全量"内容打包，以便根据"tag"进行部署或交付
3. 版本号规则，一般是3到4位；
示例：
主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]] （windows风格，1.1.0.123）
主版本号 . 子版本号 [. 修正版本号[ build- 编译版本号 ]] （GNU风格，1.2.0、1.2.0 build-1234）
4. 对外时，又有alpha, beta；普通版、专业版、企业版等等的概念