Ops.CI/CD-持续交付概要笔记

最新推荐文章于 2024-10-31 14:04:03 发布

weixin_30706691

最新推荐文章于 2024-10-31 14:04:03 发布

阅读量113

点赞数

文章标签：运维数据库 git

原文链接：http://www.cnblogs.com/seasonley/p/10853450.html

版权

持续交付价值

在保证交付质量的前提下，加快交付速度，从而更快地得到市场反馈，引领产品方向，最终扩大收益。
对CTO：环境管理，整套标准规范落地，提高跨部门协作效率，快速恢复故障（回滚）
对team leader:只是传承，专注业务而非工程，平稳节奏持续工作
对产品经理：即时体验，熟悉进度质量，产品随时可发布

影响持续交付的因素

期望组织文化

紧密配合，集思广益，自我驱动
方案：

成立项目管理办公室（但不要把流程变得更加复杂），
独立工程效能部门（成本高，小团队不适用）
敏捷开发（个人能力要求高）
打破流程因素：耗时长，人工，信息报备

架构

系统架构

单体架构：项目编译、回归、部署时间随仓库变大而变长
SOA架构：服务拆分利于实施，考虑服务之间的依赖、环境隔离，中间件适配
微服务架构：非容器技术的微服务架构与SOA基本一致

部署架构

同意的部署标准方式
发布的编排次序（灰度发布策略，如：金丝雀发布/滚动发布）
markdown markup(服务拉入拉出机制)
预热与自检

DevOps:

技术(自动化运维，持续交付，高频部署、Docker)/职能/文化/组织架构

分支策略

主干开发（trunk based dev）

优点：无需分支切换；频繁集成冲突少、效率高
缺点：短板效应；借助特性切换会引入新问题
适用项目：团队系统设计开发能力强，有特性切换方案，快速迭代

特性分支开发

类别
- git flow：普遍认为hotfix和release显得多余。适用项目：有预订的发布周期，严格执行发布流程。
- github flow：流程简单易上手，适用项目：随时集成即可发布
- gitlab flow：github flow基础上衍生出3个特性分支production,enviroment,release,适用项目：随时准备发布，需要通过不同环境测试，对外发布维护不同版本。
优点：不同功能互不干扰，保证主干分支质量
缺点：需要即时merge，每个分支的CI/CD环境不同

依赖管理特性

统一的命名规则，中心仓库，配置文件，本地可解析

代码回滚

个人分支回滚

可以用git reset --hard

集成分支上线前回滚

可在gitlab上找到对应的merge request，点击revert

集成分支上线后回滚

在集成分支头上增加一个commit，该内容等于回滚后对应的commit

测试环境

5大类：开发环境，功能测试环境，验收测试环境，预发布环境，生产环境
成本：机器；管理（可用，配置，测试数据）；流程（沟通，测试）
自描述：
- 定义ServerSpec(描述文件，服务器的所有身份信息)
- 配置中心（构建时配置，打包时配置，运行时配置）
- 服务自发现（根据服务类型，访问路径等自动生成对应的路由负载均衡配置等）

快速构建测试环境

虚拟机环境：物理机硬件配置，系统与网络，利用工具自动配置环境
应用部署流水线：单应用标准化部署，并行，容错：错误中断/优先完成
环境变更：入口管理-约定大于配置，调用链管理-自发现，数据库-SOA调用链/来自生产快速创建；创建和拆分、合并后的环境冲突。

容器

概念：是软件的一个轻量的、独立的、可执行包，包括了执行它所需要的所有内容：代码、运行环境、系统工具、系统库、设置。
特性：交付结果一致，交付自动化，交付个性化，交付版本控制

构建提速

升级硬件，搭建私有仓库，使用本地缓存，规范构建流程，善用共建工具
持续集成工具：Travis CI,Circle CI,Jenkins CI,Gitlab CI

容器镜像

DooD

(Docker-outside-of-Docker):是指通过加载宿主Docker socket和程序的方式达成重用宿主镜像的目的。

优点：复用镜像共建环境，宿主机只需安装Docker Daemon
缺点：内部环境需与外部一致，Docker Daemon出问题影响其他容器。

DinD

(Docker in Docker):在容器中安装一个全新的完整的隔离的Docker版本，该容器和外部的Docker系统完全隔离。

优点：内部是一个完整的镜像构建环境
缺点：安全和文件系统问题，构建性能（镜像缓存随容器重启而消失）

容器个性化&合规检查

自定义环境脚本（.pass），平台化环境选项与服务集市，自定义镜像发布

发布流程

单机发布抽象步骤：
1. 下载新的版本，不执行覆盖；
2. 通知上游调用方，自己现在为暂停服务状态；
3. 运行命令 load 变更重启服务；
4. 验证服务的健康状况；
5. 通知上游调用方，自己服务恢复正常。
集群灰度发布：蓝绿发布，滚动发布，金丝雀发布
不可变模型（Immutable）：任何基础设施的实例一旦创建则只读，如需修改或升级只能创建新实例来替换

灰度发布系统设计

类目：集群，实例，发布日志，发布历史，发布批次，发布操作
2种时态：
- 发布中：展示处理的过程，结果，耗时，当前情况
- 未发布时：显示版本演进路线图，当前各集群，服务器上具体版本的情况
3种结果：成功，失败，中断
4种情况按钮组合（谁发布，谁运行）：
- 开始发布
- 中断发布
- 中断或重试发布（局部错误时）
- 中断或继续发布（发布刹车时）
5个发布步骤(演进自上述单机发布抽象步骤)
- markdown：拉出集群
- download：根据版本号下载代码包
- install：停止服务、替换代码、重启服务
- verify：启动、预检、预热
- markup：拉回集群
- 策略：单机单应用优于单机多应用，全量发布优于增量发布，header附加堡垒标识从而保证堡垒机流量定向