DEVOPS的基本体系与流程

小咪咪 2022-10-05 00:42 186阅读 0赞

大体上，我们可以将devops的体系划分为三块：代码、配置与部署环境

# 代码 #

良好的代码管理准则是：开发用分支，部署用TAG

理想情况下，我们的永久分支只有一个master，除非有LTS(对某个版本长期支持)的要求。

功能开发使用feature-\*，测试通过，合并到master分支后应立即删除

BUG修复使用hotfix-\*，测试通过，合并到master分支后应立即删除

多余的分支都是在增加代码管理与部署的复杂度

# 配置 #

需要强调的是：配置不应该成为代码的一部分

首先为配置定义以下几个维度：

若将各个环境的配置都放在源码中，那么密钥必然会暴露给所有开发人员，就无法满足密钥保密的要求；  
若服务器计算与存储能力不尽相同，那么也无法进行性能优化；  
同时，若设置了较高的网络延时，那么对于RTT较小的网络，当发生部分服务不可用时，无法及时检测，仍然会造成较多的请求失败。

因此，代码里面应该只保留开发人员所需要的本地开发配置，并且和本地环境无关。这一点可以通过Docker做到。

# 部署环境 #

除了开发人员需要的本地开发环境外，至少还需要测试环境和生产环境。

如果有资源，测试环境可以进一步划分为联调环境，伪生产环境和准生产环境。

对应的配置如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FkcGFya2luZw_size_16_color_FFFFFF_t_70][]  
其中，伪生产可以用于验收性测试（alpha测试），准生产可用于灰度测试（beta测试）；

准生产的配置基本与生产环境一致，联调环境的配置基本与伪生产环境一致；  
若资源不足，可以减去联调环境与准生产环境。

# 事件与应对流程 #

### 开发新功能： ###

1.  基于master创建新的本地分支feature-\[新功能\]
2.  本地开发、测试
3.  开发完毕，使用git rebase master避免冲突, 然后推到远程分支，请求合并到master并删除该远程分支
4.  合并master并删除完毕，发布到测试环境
5.  测试不通过，则回到第1步;测试通过则结束
6.  最后，待本次迭代内的所有特性均完成了测试，那么在master上面打TAG，准备发布新版本。

### 修复线上BUG： ###

1.  基于线上版本的TAG创建新的分支hotfix-\[BUG\]
2.  本地开发、测试
3.  修复完毕，推到远程分支
4.  将该远程分支发布到测试环境
5.  测试不通过，则回到第2步；测试通过，则合到master并删除该分支，打TAG，准备发布补丁版本

### 版本发布/回滚： ###

1.  迭代开发完毕，基于新版本的TAG，发布到生产环境
2.  回滚时，基于上个版本的TAG发布到生产环境
3.  热修复时，基于热修复版本的TAG发布到生产环境

## 代码与部署环境的对应发布方式   ![20210607110227826.png][] ##

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FkcGFya2luZw_size_16_color_FFFFFF_t_70]: /images/20221005/350da25c42f44b6b950fa5fda73b0188.png
[20210607110227826.png]: /images/20221005/1fd5e915986e41ab898dcfa31b6f6288.png