一种devops实践方法的总结。
remote repos
- 推荐放置于github
- 最新可部署代码放置于master分支。由项目代码的code master掌管，其他人不允许直接push到这个分支。
- spec design. architecture（如果不是独立的role，那么所有承担此角色的人要一起来讨论spec的设计）。
- developer开新分支，根据spec编写unit-test和implementation code。此处可以采用Test-driven development。自行进行功能测试，包含unit-test以及end-2-end test。撰写部署脚本。git push。然后到github创建pull request并请求code master进行1-to-1 code review，review通过由master merge代码。
spec design
spec design要由architecturer role / group来完成，包含：
- api定义
- 函数名称（名称的自解释性非常重要！！）
- 业务逻辑，即函数应该完成的功能
- 入参名称，数据结构定义，默认值等
- 返回结果的数据结构，数据结构中的每个字段的名字、属性、默认值等
- 异常定义，异常代码，异常信息
- 特性定义，比如幂等性（应该幂等还是不幂等？）、健壮性（是否应该积极抛出异常，还是默默容错？）、副作用（是否应该是pure的？是否应该stateless？），等等
- model定义
- model的命名
- 数据结构定义，数据结构中的每个字段的名字、属性、默认值等
- 数据迁移定义（比如django的migrations）
架构师最好统一把migrations生成（避免硬分叉冲突），并把prototype也落实成代码，以便dev直接在其中补齐逻辑实现即可。
补充：对于存在ORM migrate的架构，推荐把model升级和code升级分成两步，先migrate model（形成一个commit point），确保没问题之后再upgrade code，这样，如果第二步失败需要回滚，则只需要回滚到第一步的commit point。
建议由architecturer (dev arch)来做。
deployment
- 由devops完成（或分担此角色的人共同完成，结对）
- 规划代码部署位置，推荐在/opt/{APP_NAME}
- git pull
- 重启服务，比如对于systemd守护的服务，使用sudo service SERVICE_NAME restart
- 查看服务状态，包括但不限于：
- service XXX status 查看systemd service的状态
- ps aux | grep XXX 查看进程运行否
- netstat -na | grep XXX 查看服务是否正在监听相关端口
- APP自身的status查看方法
- 最后一定要做一次生产环境的end-2-end test！
rollback
如果部署失败需要回滚，可以使用git，具体方法是：
- git log找到上一次部署的commit
- git checkout LAST_COMMIT -b rollback
- 此时代码切换到rollback分支，且filesystem上的code files回复到LAST_COMMIT的状态
- 重启服务。检查状态。做end-2-end test。确保回滚成功。
然后，开始腾出手来仔细检查为何master的code部署失败。fix并重新部署。
成功后，删除rollback分支。
