DEVOPS的基本体系与流程

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/ligen2012/article/details/78553177

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

代码

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

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

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

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

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

配置

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

首先为配置定义以下几个维度:
日志级别:DEBUG|INFO|ERORR
数据持久化(即是否为生产数据库):真|伪
性能要求(比如线程池、连接池):低|高
网络敏感度(即调用外部服务的延时容忍度):低|高
密钥可见性(需要进行认证的各种服务): 公开|透明

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

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

部署环境

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

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

对应的配置如下:

配置项\环境 本地开发 联调 伪生产 准生产 生产
日志级别 DEBUG DEBUG INFO INFO ERROR
持久化
性能要求
网络敏感
密钥可见性 公开 透明 透明 透明 透明

其中,伪生产可以用于验收性测试(alpha测试),准生产可用于灰度测试(beta测试);
准生产的配置基本与生产环境一致,联调环境的配置基本与伪生产环境一致;
若资源不足,可以减去联调环境与准生产环境。

事件与应对流程

开发新功能:

  1. 基于master创建新的本地分支feature-[新功能]
  2. 本地开发、测试
  3. 开发完毕,使用git rebase master避免冲突, 然后推到远程分支,请求合并到master并删除该远程分支
  4. 合并master并删除完毕,发布到测试环境
  5. 测试不通过,则回到第1步;测试通过则结束

最后,待本次迭代内的所有特性均完成了测试,那么在master上面打TAG,准备发布新版本。

修复线上BUG:

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

版本发布/回滚:

  • 迭代开发完毕,基于新版本的TAG,发布到生产环境
  • 回滚时,基于上个版本的TAG发布到生产环境
  • 热修复时,基于热修复版本的TAG发布到生产环境

代码与部署环境的对应发布方式

分支\环境 本地开发 测试 生产
feature-* 基于本地文件 X X
hotfix-* 基于本地文件 基于分支 X
master X 基于分支 基于TAG

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试