总览
将 DevOps 实施的过程分为了这么几个步骤:
- 建立愿景与方向
- 度量:组织、系统现状
- 准入条件。查看是否满足实施 DevOps 的准入条件。
- 探索可行方案。即 MVP 尝试
- MVP。一次快速的 DevOps 过程和结果的 showcase。
- 精细的 DevOps 实施
- 回顾优化
- 规模化 DevOps 落地
对应的在手册中,还包含了
- 附录 1:移动应用的自动化测试
- 附录 2:可信软件系统 10 要素
- 附录 3:基本概念
建立愿景与方向
启动会议
利益相关者会议
业务关注点
组成部分标题 | 内容 |
---|---|
问题 | 为什么对组织来说引入 DevOps 实践是有好处的? |
成本 | 引入 DevOps 实践的预期成本是什么? |
干系人影响 | 对内部和外部干系人的影响是什么? |
风险和缓解 | 与引入 DevOps 实践相关联的组织和技术风险是什么?如何减缓这些风险? |
推出计划 | 推出 DevOps 的实践计划是什么? |
成功标准 | 我们如何知道 DevOps 实践的引入是成功的 ? |
—— 《DevOps 架构师行动指南》
识别目标和现状
自评
差距分析
确认团队
优先选择优秀的团队?
设立里程碑
时间节点-团队-活动-产出表
落地策略
DevOps 转型策略
自行落地
1. 组织层级解决跨团队协作
2. 建立 DevOps 知识库
顺带一提,Ledge 已经成为了多个 DevOps 公司的内部资料库的外部参考资源。
3. 培养内部专职教练
- 按需选择人员培养
- 构建人员成长模型
- 设计成长路径
- 监督成长
供应商
1. 避免供应商锁定
供应商锁定通常被定义为“专利锁定或客户锁定,这使得客户依赖于供应商的产品和服务,无法在不产生大量切换成本的情况下使用其他供应商。
2. 培养内部能力
外部教练
1. 结对模式
2. 赋能团队
3. 内部总结分享
度量与评估
可视化现状和未来
Path to Production
Path to Production,来源于精益,旨在通过可视化的方式来展示项目的上线流程,并优化过程中的瓶颈问题。它类似于我们使用 CI(持续集成)时的 Pipeline。传统的 Pipeline 的 gate 可以通过代码定义一些标准,由测试不能挂,测试覆盖率不能低于多少,打包不能失败等等。而这些 Pipeline 则是分别由开发人员、测试人员、运维人员、项目负责人等等来负责把控的。
对应的,在这个过程中:流程(Process)、人(People)、工具(Tooling)、产物(Artifacts) 都是我们的关注点:
- Process,即上线需要多少流程。从提交代码开始,运行持续集成,部署到 Dev 环境等等。
- People,即过程中需要哪些人来参与。如需要开发人员提交代码,需要测试人员进行 QA 环境部署,需要项目经理等高级领导进行上线审批等。
- Tooling,即需要使用哪些工具来完成上线。如托管代码的 Git 服务器,运行构建的持续集成工具,提交上线申请的相关工具等等。
- Artifacts,即过程中产出的产物。如生成的应用包,QA 生成的测试报告等等。
随后,我们从相关的流程中,梳理出每个部分(流程)的持续时间、痛点,来查找优化空间。
《如何优化上线流程——Path to Production》
示例:
活动 | stage 1 | stage 1 | stage 1 | stage 1 | stage 1 | stage 1 | stage 1 | stage 1 | stage 1 |
---|---|---|---|---|---|---|---|---|---|
流程 | 提交代码 | 运行 CI | 部署到 Dev 环境 | 运行 E2E 测试 | 手动测试 | 部署到 ST/UAT | 手动测试 | 上线申请 | 上线 |
人 | Dev | Dev | Dev | Dev | Dev | 项目 QA | 业务 QA | 业务 QA | PM |
工具 | Git & GitHub | Jenkins | Jenkins | Jenkins | - | Jenkins | - | 邮件 | - |
制品 | 代码 | 持续集成结果 | - | 测试报告 | 测试报告 | - | 邮件结果 | - |
Path to DevOps
源码管理 | 制品管理 | 配置管理 | 数据库自动化 | 测试 | 持续集成 | 监控 | 分析 | 智能运维 | 协作 |
---|---|---|---|---|---|---|---|---|---|
--- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
确认 DevOps 流程
DevOps 流程
- 规划
- 编码
- 构建
- 测试
- 发布
- 部署
- 运维
- 监控
DevOps 框架
—— 出自《DevOps 最佳实践》
- DevOps 持续测试。
- DevOps 敏捷开发。
- DevOps 持续集成。
- DevOps 持续交付。
- DevOps 持续监控。
- DevOps 敏捷流程。
度量效能
DevOps 四个关键指标
- 提升交付效能
- 部署频率
- 批量的大小
- 自动化程度
- 测试效率
- 部署效率
- 构建效率
- ……
- 交付前置时间
- 需求稳定性
- 任务交接
- 等待时间
- 团队速度
- 返工率
- ……
- 平均恢复时间
- 监测的效率
- 系统可配置性
- 系统可维护性
- 日志可用性
- 架构质量
- ……
- 变更失败率
- 自动化程度
- 架构质量
- 基础设施即代码
- 测试质量
- 测试代码质量
- 代码质量
- 编码规范
- 重复代码
- 测试覆盖率
- 扇入扇出度
- 圈复杂度
- ……
《持续交付 2.0》中提到了一种不错的软件产品的交付效能度量方式:
- 软件产品的交付效能
- 速度
- 需求响应能力
- Feature Lead Time(业务需求前置周期)
- User Story Delivery Time(用户故事交付周期)
- 持续发布能力
- Integration Testing Time(集成测试周期)
- Release Frequency Time(发布频率)
- MTT(X)(X 的平时时长,X = 发布 | 升级 | 缓解 | 解决)
- 质量
- 发布前质量
- Remain Bugs(单位周期的遗留缺陷数)
- Bugs/User Story(单个用户故事发现的缺陷数)
- 发布后质量
- Change Failure Rate(变更失败率)
- Issues(单位时间内的生产环境故障数)
- 价值
- 需求吞吐量
- Total Features(单位时间内交付的业务需求数)
- 交付有效性
- Success Rate(业务需求的成功率)
度量
度量分支策略
简单来说就,就是我们应该从软件的发布模型,倒推出软件的分支策略。
度量构建
是否拥有构建?
统计:
- 失败次数。
- 失败原因。常见:环境问题、专业度问题
- 构建时间。
- 构建流程。
- 如何管理依赖。
代码覆盖率
- Java
- JavaScript
- Go
代码质量分析工具
度量团队和组织
团队状态评估
- 人员流动情况
- 加班情况
- 对于转型的认可度
- 对于 DevOps 活动的支持程度
团队组成和能力水平
各个角色组成和人员比例
人员成长模型
技术债务评估
对于技术债务,它的利息表现为系统的不稳定性,以及由于临时性手段和缺乏合适的设计、文档工作和测试带来的不断攀升的维护成本。 —— 《架构师应该知道的 97 件事》
如 Robert Nord 提出的 “技术债务全景图”(Tech Debt Landscape) 所示:
技术债对于软件的影响:可维护性(Maintainability)、可演进性(Evolvability),而这些技术债对于非技术人员来说都是不可见的。它们源于生活,藏于黑暗中。
技术债务收集
技术债头脑风暴
- 团队一起列出潜在的技术债
- 归纳、分类技术债
- 优先级排序
- 物理板可视化
开发时
来源:《技术债务墙:让技术债务无所遁形)》
在开发代码时你要想想:
- 是什么让你的速度变慢了?是什么让代码变得难以理解?是什么原因导致 bug 难以跟踪?什么东西应该被更好地记录下来或测试?在便利贴上记下你碰到的任何一个技术债务。保持简短,但要确保你以后仍然看得懂。
- 估计机会成本:如果不存在这个问题,你原本有多少时间可以用在其他事情上?把它写在便利贴上。确定好时间标记,例如用点号表示半天。视觉化比是否精确更重要。
- 估计解决这个技术债务需要多长时间,把它记下来。
- 或者记下如何解决技术债务。你可能会把它记在问题跟踪系统中,那么就把问题编号写在便利贴上。
- 把便利贴贴在技术债务墙上。
- 如果有人遇到同样的问题,添加更多的标记,用来表示他们付出的时间成本。
DevOps 维度模型
如:
- 规范落地的可持续性
- 单一可信源
- 版本可回溯
- 测试分层策略
准入条件
目标:以提升能力为核心。
有意愿的组织
有意愿的团队
- 有时间
- 有精力
- 有人
- 有 KPI
团队发展阶段模型
Bruck Tuckman 团队发展模型:
- 组建期
- 激荡期
- 规范期
- 执行期
- 休整期
守 -> 破 -> 离
- 组建期和激荡期:建立信任
- 搞定问题的能力
- 积极主动的态度
- 团队合作的意识
- 规范期和执行期:关注价值流程
- "拉动"
- 执行期:仪式感
- ''
—— 来自《深入核心的敏捷开发》
有意愿、能力的个人
DevOps 外部教练
DevOps 内部教练
学习计划
组织提供支持
DevOps 实施看板
可视化现状
DevOps 实施看板
- 团队实施看板
- 组织实施看板
- DevOps 团队实施看板
- Todo
- 讨论 E2E 测试方案
- 引入 SonarQube 质量门禁
- 本地代码预提交
- 工具化提交信息规范
- 单元测试培训
- Doing
- 流水线集成自动化测试
- 可视化测试覆盖率
- 引入后端测试框架
- 引入前端测试框架
- Check
- 制定测试实施计划
- 制定测试策略
- Done
- 测试策略分享
组织实施看板
- DevOps 组织实施看板
- Todo
- 搭建标准化测试环境
- 搭建端到端自动化测试环境
- 引入 DevSecOps 工具:Anchore
- Doing
- 集成 TypeScript 测试覆盖率
- 引入 DevSecOps 工具:Dependency-Check
- Check
- 集成 Java 测试覆盖率
- 制定提交信息规范
- 设计 DevSecOps 流程
- Done
- 搭建 Jenkins
- 搭建 SonarQube
- 搭建 Nexus
探索可行方案
可构建
不可构建的系统?
分解构建过程
——《Java 持续交付》
常规构建步骤:
- 校验。校验项目是否正确,并且所有的必要信息是否都存在?
- 编译。编译项目的源代码
- 测试。使用合适的单元测试框架中来测试编译后的源代码
- 打包。将已编译的代码打包为可分发的版本
- 确认。检查集成测试的运行结果,确保系统满足质量标准
- 安装。将软件包安装到本地仓库中,以便在本地环境中用作其他项目的依赖项
- 部署。在构建环境中完成部署,将最终的打包制品复制到远程仓库,以便与其他开发人员和项目共享。
遗留系统问题
9 种遗留系统现代化的技术
发生变化的方面 | Retain | Retire | Encapsulation | Rehost | Replatform | Refactor | Rearchitecture | Rebuild | Repuchase |
---|---|---|---|---|---|---|---|---|---|
产品功能 | No | No | No | No | No | Yes | No | Yes | Yes |
架构 | No | No | Yes | No | Yes | No | Yes | Yes | Yes |
基础设施 | No | No | No | Yes | Yes | No | Yes | Yes | Yes |
代码 | No | No | No | No | Yes | No | Yes | Yes | Yes |
出处:《Legacy System Modernization: How to Transform the Enterprise for Digital Future》
测试策略
总体方案
- 先前期调研,看看自动化可行性,定位自动化测试的测试目的
- 制定策略,定自动化测试目标比例
- 框架选型、准备环境、准备 demo
- 框架搭建、跑通、集成 CI,大家一起补测试
- 管理数据和用例
- 持续更新
示例:
- 可测试性调研
- 评估自动化可行性
- 定位自动化测试的测试目的
- 进行自动化测试赋能
- 测试赋能计划
- 制定自动化测试目标比例
- 制定和落地分级测试策略
- 通用的应用级测试策略模板
- 设计环境管理、数据管理、用例管理方案
- 对齐标准的测试环境
- 建立 Dev、QA 测试环境
- 建立自动化测试环境
- 测试环境打通
- 建立可持续性的测试知识库
- 建立种类丰富的测试类型文档中心
- 收集业内的测试种类和测试策略
测试策略
测什么
| 需求分析 | 开发前 | 开发 | 开发完成 | 测试| 发布前|已发布 |
|--|--|--|--|--|--|--|
| 用户故事评审 | 特性启动 | 单元测试 | 用户故事验收 | 用户故事测试 | 回归测试 | 监控 |
| 估算 | 测试用例设计 | 组件测试 | 底层测试评审 | 探索式测试 | 发布指南 | 支持 |
| 方案设计 | 用户故事启动 | | 发布可测试版本 | 缺陷管理 | 用户验收测试 | 质量分析 |
| 迭代计划 | 测试计划 | | | 风险评估 | 发布版本确认 | |
| | | | | 集成测试 | | |
| | | | | 端到端测试 | | |
config: {"colors": [{"bg":"#e55852","font":"#b71a09"},{"bg":"#e98832","font":"#c85113"},{"bg":"#f0d668","font":"#b88d0f"},{"bg":"#a4c9cf","font":"#598893"},{"bg":"#47c0af","font":"#175a54"},{"bg":"#387fd5","font":"#9ac9f5"},{"bg":"#7753df","font":"#cbb5f8"}]}
软件质量评估模型
- 软件质量评估模型
- 测试覆盖度评估
- 需求覆盖度评估
- 路径覆盖度评估
- 测试过程评估
- 测试用例分析
- 测试方法分析
- 测试投入分析
- 缺陷分析
- 缺陷密度分析
- 缺陷修复情况分析
- 缺陷趋势分析
- 缺陷年龄分析
- 缺陷触发因素分析
常见测试类型
见《测试架构师修炼之道》
常见测试类型及其与质量属性关系表
名称 | 说明 | 对应的质量属性 |
---|---|---|
功能测试 | 验证产品能否满足用户特定功能要求并做出正确响应 | 功能性 |
安全性测试 | 验证产品是否有保护数据的能力,并能在合适的范围内承受恶意攻击 | 功能性 |
兼容性测试 | 验证产品是否能够和其他相关产品顺利对接 | 功能性 |
配置测试 | 验证产品是否能够在推荐配置上流畅运行;验证产品为了完成特定功能的输入是否会出现故障 | 功能性,易用性 |
可靠性测试 | 验证产品在长时间运行下能否满足保证系统的性能水平;在存在异常的情况下系统是否依然可靠 | 可靠性 |
易用性测试 | 验证产品是否易于理解、易于学习和易于操作 | 易用性 |
性能测试 | 测试产品提供某项功能时的时间和资源使用情况 | 效率 |
安装测试 | 测试产品能否被正确安装并运行 | 可移植性 |
探索式测试
探索式测试作为系统测试与系统集成测试的补充,执行在手工系统测试和系统集成测试之后。以固定时间窗方式探索系统尝试发现潜在缺陷。
- 基于对系统的理解准备测试方案与大纲。
- 以系统主干功能为脉络,测试大纲为指导,在规定时间窗之内执行探索式测试,发现可能存在的问题。
- 根据新的认知设计、新的测试大纲并执行测试。周期性以系统团队为单位总结并沉淀启发式列表,用以作为后续测试执行的参考。
APP 测试类型
- 测试类型
- 基础测试
- 功能测试 (Function Test)
- 集成测试(Integration Test )
- 单元测试(Unit Test)
- 契约测试(Contract Test)
- 进阶测试
- 兼容测试(Compatibility Test)
- UI视觉测试(UI Visual Test)
- 性能轮廓(Profiling)
- 安全测试(Security Test)
- 异常测试(Exception Test)
- 猴子测试(Monkey Test)
- 安装、升级和卸载测试(Install、Upgrade and Uninstall Test)
- 耐久测试(Endurance Test)
- 耗电测试(Power Consumption Test)
- 流量测试(Network Traffic Test)
- 其他硬件功能专项测试
- 产品测试
- 易用性测试(Usability Test)
- A/B测试(A/B Test)
- 产品在线测试(Product Verification Test or Product Online Test)
- 用户测试(Customer Test
定义测试类型
类型 | 说明 |
---|---|
测试类型 | |
测试说明 | |
测试范围 | |
技术 | |
准入标准 | |
准出标准 | |
特殊事项 | |
环境 |
兼容性测试
腾讯移动分析:https://mta.qq.com/mta/data/device/resolution
设备分辨率:https://viewportsizer.com/devices/
测试流程设计
示例:
- 开发前
- :success
- 测试用例设计:success
- 测试计划:success
- 开发
- :success
- 单元测试:success
- 组件测试:success
- 开发完成
- :success
- 用户故事验收:success
- 底层测试评审:success
- 测试
- :success
- 接口测试:success
- 集成测试:success
- 探索性测试:success
- 特性稳定
- :success
- 编写端到端测试:success
常见测试工具
常见的测试策略组合:
- 框架/模式库测试。xUnit,xMock,如 Java 语言里的 JUnit, Mockito;JavaScript 中的 Jest
- 端到端 API 测试。JMeter,Postman,Rest Assured,Karate
- UI 集成测试。Protractor
考虑到测试即文档,在实现实现的时候,会配合一些支持自然语言描述的框架,如:
- 文档式测试,Gauge (主流语言),Concordion(Java)
- BDD 测试,Cucumber(主流语言)
- ATDD 测试,Robot Framework(Python 语言)
为了与运行客户端一配合,我们还需要有底层 API 来控制浏览器、客户端应用:
- Appium。移动 APP 和桌面应用,支持主流语言
- Selenium。Web 浏览器,支持主流语言
- Puppeteer。Node.js API 操作 Chrome 浏览器
API 测试
工具
工具 | 项目地址 |
---|---|
ApacheBench | https://httpd.apache.org/docs/2.4/programs/ab.html |
wrk | https://github.com/wg/wrk |
Apache JMeter | https://jmeter.apache.org/ |
Locust | https://locust.io/ |
K6 | https://k6.io/ |
Artillery | https://artillery.io/ |
Vegeta | https://github.com/tsenart/vegeta |
对比
项目 | 价格 | 数量 | locust | jmeter |
---|---|---|---|---|
工具 | wrk | ab | locust | jmeter |
安装 | 简单 | 简单 | 依赖 python | 依赖 jdk |
场景压测 | 不支持 | 不支持 | 支持 | 支持 |
UI 界面 | 无 | 无 | 有 | 有 |
脚本录制 | 无 | 无 | 无 | 利用本地 ProxyServer 或 badboy |
资源监控 | 无 | 无 | 无 | 通过 JMeterPlugins 插件和 ServerAgent 实现 |
报告分析 | 无 | 无 | 无 | 生成 HTML 报告 |
测试可视化
JMeter + Grafana + influxDB
Robot + Jenkins
测试遗留系统
如我在《系统重构与迁移指南》一书中指出,要给遗留系统项目加测试并不是一件容易的事情。你需要找到对应年代的测试框架,熟悉对应年代的技术栈,然后才能一点点切入系统。
而后,当你遇到诸如 Java 中的 static 方法调用链时,你会发现难以继续往下,便得想着办法重构。而因为没有测试,你又没有办法重构。
重构没有测试,测试加不了?
持续集成阶段设计
实施过程步骤:
- 流水线 hello, world
- 构建和部署流程自动化
- 单元测试自动化
- 集成现有代码分析服务
- 验收测试自动化
- 发布自动化
普通流水线模型
来自《持续交付 2.0》的示例:
多流水线模型
开源模式
PR 流水线
技术实践设计
提交规范
提交信息规范
预本地提交
预服务器提交
制定代码规范
Checkstyle
Lint
自动修复工具
- Prettier 是一个代码风格统一工具。
- esLint
ng lint --fix
代码回顾
多团队探索
如《架构师修炼之道》的『方法 15:分而治之』所建议的探索案例:
第一周的探索案例:
小组 | 探索任务 | 展示与说明 |
---|---|---|
1 | 重构插件框架,判断原有代码库能否复用 | 展示重构的主要接口和类,说明计划是可行的 |
2 | 尝试 gRPC 服务 | 演示 Ruby 客户端与 Java 服务端的通讯 |
3 | 创建概念图并设计微服务分区 | 展示初步概念图。说明还有这么多工作要做 |
第二周的探索案例:
小组 | 探索任务 | 展示与说明 |
---|---|---|
1 | 通过命令行调用原有插件 | 比预计的工作量多。说明存在哪些障碍,以及计划如何补救 |
2 | 寻找合适的数据库 | 比较三种数据库的优劣(快速浏览其代码) |
3 | 完善概念图,继续设计微服务分区 | 展示概念图和微服务的分区设计 |
选择方案
各步骤方案
如 《DevOps 实施手册:在多级 IT 企业中使用 DevOps》 所介绍的 DevOps 实施方案,几点要求:
- 明确界定目标状态(业余目标及驱动力)
- 理解现状(能力及成熟度模型)
- 识别交付流水中效率低下领域的瓶颈问题(通过实施价值流程图)
结合之下我们有了初步的方案选择:
- 建议衡量标准与关键绩效指标
- 项目关键绩效指标
- 速度
- 成本
- 关键绩效指标组合
- 质量关键绩效指标
- 交付流水线优化关键绩效指标
- 文化关键绩效指标
- 敏捷实施
- 自动化部署
- 进入类生产环境
- 自动化测试
- 监控与反馈
- 集成的交付流水线
- 实现端到端的可追溯性
- 带有多重交付流水线的多级 IT
- 持续集成
- 持续交付
- 自动化部署
- 数据库部署
- 部署内容、方式及环境
- 持续集成到持续交付
- 推送及拉取
- 实施持续交付
- 持续交付平台
- 测试前移
- 自动化测试与持续测试
- 测试服务及环境虚拟化
- 测试数据管理
- 运维参与前移
- 转变运维角色
- IT 服务管理与 DevOps
- 持续监控及反馈
- 提供监控与反馈
- 持续改进
- 发布管理
- 发布流程管理
- 非持续发布周期的持续交付
设计度量体系
人员能力模型
DevOps 模型
过程改进模型
MVP
基础设施完善
统一依赖管理
- 制品管理。统一、专业的制品库工具(如 Nexus、Harbor 等)在项目中成熟运用
- 单一可信数据源。单一可信数据源是一种信息数据模型和关联模式,保证每个数据元素只存储一份,确保数据的一致性。
Nexus 私服
Nexus 是 Maven 仓库管理器,也可以叫 Maven 的私服。 Nexus 是一个强大的 Maven 仓库管理器,它极大地简化了自己内部仓库的维护和外部仓库的访问。
npm 源
Verdaccio is a simple, zero-config-required local private npm registry.
标准的研发环境
一键式安装
规划示例
阶段 1:规范和标准制定 | 阶段 1.5:现状调研和评估 | 阶段 2.0: 一体化平台调研与规划 | 阶段 2.5:工程教程的赋能 | |
---|---|---|---|---|
目标 | ||||
周期及范围 | ||||
总要举措 | 调研:<br> 规划: <br> 协调: | |||
产出物 | ||||
资源及职责 |
技术债务可视化
可视化
技术债看板
- 技术债看板
- Todo
- Lodash 体积过大
- Doing
- Done
- Jasmine -> Jest
技术债热力图
服务级别热力图
代码热力图?
{
"series": [
{
"type": "treemap",
"breadcrumb": {"show": false},
"roam": "false",
"nodeClick": "false",
"data": [{
"name": "nodeA","value": 10,
"children": [
{"name": "HealthController.java", "value": 4 },
{"name": "HealthService.java", "value": 6}
]},
{"name": "HealthModel.java", "value": 20}
]
}
]
}
技术债墙
- 技术债墙
- 快速解决
- ……
- ……
- ……
- 分解并计划
- ……
- ……
- ……
- 在可能的时候提升
- ……
- ……
- 暂时不管
- ……
- ……
- ……
config: {"left": "简单", "right": "困难", "bottom": "不重要", "top": "重要"}
技术债务评估
相关文章:
审视架构
可视化架构
C4 模型
—— 《程序员必读之软件架构》
C4 模型由一系列分层的软件架构图组成,这些架构图用于描述上下文、容器、组件和代码。C4 图的层次结构提供了不同的抽象级别,每种抽象级别都与不同的受众有关。
- 系统上下文。设定场景的高层次图,包括关键的系统依赖和参与者。
- 我们构建的软件系统是什么?
- 谁会用它?
- 如何融入已有的 IT 环境?
- 容器。容器图显示了高层次的技术选择,容器如何分担职责、如何通信。
- 软件系统的整体形态是什么样的?
- 高层次技术决策有哪些?
- 职责在系统中如何分布?
- 容器之间如何进行交流?
- 开发者需要在哪里写代码?
- 组件。组件图可以让你看到每个容器的关键逻辑组件及之间的关系。
- 系统由哪些组件/服务组成?
- 在高层次上,系统如何工作、是否清晰?
- 所有组件/服务都驻留在一个容器中?
- 类。这是一个可靠的细节层次。类是软件系统的最小结构单位。
嗯
-此处应有 C4 图示例-
调整架构
康威定律
在设计系统时,组织所交付的方案结构将不可避免地与其沟通结构一致。 —— 梅尔文·康威
康威逆定律
构建与目标系统架构相仿的团队结构,这样项目会更容易实现。
领域驱动设计
事件风暴
事件风暴。它是由 AlbertoBrandolini 提出的,一种用于领域驱动设计的协作设计方法。 事件风暴基于现实业务流程,以系统实现为视角,通过一次只关注一个维度的分层抽象方式,将现实业务流程进行抽象并转化为系统实现的业务逻辑。
它的流程是,通过识别决策命令(decision command)和领域事件(domain event)的聚合(aggregate) or 业务承载物(carrier),并开始将聚合分组到有界上下文中。梳理限界上下文依赖关系,再划分问题子域中。在此过程中,识别关键测试场景,用户和目标并将其合并到模型中。最后,添加有界上下文之间的关系以创建上下文映射。然后用代码对所得模型进行挑战,以验证组学习并验证模型。
它通常由三个步骤组成:
- 头脑风暴,以识别领域事件。
- 识别事件触发器(决策命令)。
- 识别聚合(业务承载物)。
模型探讨旋涡(whirlpool)是由 DDD 的创造者 Eric Evans 创建的一个模型探讨漩涡的文档草案(http://domainlanguage.com/ddd/whirlpool/ )。这份文档提出了一种建模和知识提炼的方法,它能补充其它的敏捷方法,并能在应用的开发生命周期中随时使用。不过,它主要不是用来建模的,而是为了解决在创建模型期间遇到的问题。
来源:《如何通过 DDD(领域驱动设计) 降低软件开发的成本?》
搭建持续集成
Jenkins
GoCD
代码化构建流
编程式
Bash
Gradle
aka Groovy
Kotlin Script
Makefile
Go 示例:
all: clean build
build: build-linux build-windows build-macos
test:
# make build-plugins
$(GOTEST) -v ./...
clean:
$(GOCLEAN)
rm -rf $(BINARY_DIR)
run:
$(GOBUILD) -o $(BINARY_DIR) -v ./...
./$(BINARY_DIR)
lint:
golint ./pkg/...
changelog:
conventional-changelog -p angular -i CHANGELOG.md -s -r 0
JavaScript
通过 package.json
中的 script
字段,如 Ledge 中的:
{
"scripts": {
"ng": "./node_modules/.bin/ng",
"start": "yarn ng serve",
"build": "node --max_old_space_size=4096 ./node_modules/.bin/ng build",
"build:ci": "node --max_old_space_size=4096 ./node_modules/.bin/ng build --configuration ci",
"build:stats": "node --max_old_space_size=4096 ./node_modules/.bin/ng build --stats-json",
"analyze": "webpack-bundle-analyzer dist/ledge/stats-es2015.json",
"test": "yarn ng test",
"test:ci": "yarn ng test --watch=false --progress=false --browsers=ChromeHeadlessCI --codeCoverage",
"lint": "yarn ng lint",
"commit": "git-cz",
"package": "yarn build:ci && rm -rf dist/static && yarn scully",
"deploy": "yarn package && npx angular-cli-ghpages --repo=https://github.com/phodal/do.git --dir=dist/static --cname=devops.phodal.com",
"publish:cloudbase": "cloudbase hosting:deploy dist/static -e ledge2-8daa6a",
"build:render": "node --max_old_space_size=4096 ./node_modules/.bin/ng build @ledge-framework/render --prod",
"build:view": "node --max_old_space_size=4096 ./node_modules/.bin/ng build @ledge-framework/view --prod",
"publish:render": "cd @ledge-framework/render && npm publish --access=public",
"publish:view": "cd @ledge-framework/view && npm publish --access=public",
"scully": "scully --scanRoutes",
"scully:serve": "scully serve",
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
}
}
Pipeline as Code
Jenkins
见:Pipeline
示例:
pipeline {
agent any
options {
skipStagesAfterUnstable()
}
stages {
stage('Build') {
steps {
sh 'make'
}
}
stage('Test'){
steps {
sh 'make check'
junit 'reports/**/*.xml'
}
}
stage('Deploy') {
steps {
sh 'make publish'
}
}
}
}
GoCD
见:GoCD
代码化配置
数据库自动化
工具特性:
- 通过
迁移脚本
执行数据库变更,这些脚本是标准的 SQL 文件 - 每个迁移脚本必须有一个唯一的名称和序列号
- 迁移工具会为自己保留一张表,用来记录已经在数据库中运行过的迁移脚本,以及哪些迁移脚本尚未运行。
- 无论何时使用和迁移工具,它都会扫描所有可用的迁移脚本,与在数据库中已经记录的脚本进行比较,找出尚未运行的脚本,然后运行它们。
引入 Flyway
实施自动化测试
后端测试体系
架构测试
ArchUnit: ArchUnit 是用来检查架构特征的 Java 测试库,比如包与类的依赖关系、注解、甚至是调用层级一致性。它可以附加在现有的测试方案中,以单元测试的方式运行,但目前只能用于 Java 架构。ArchUnit 测试套件可以合并到持续集成环境及部署流水线中,使我们可以更容易地利用架构适应度函数实现演进式架构。
参见:《ArchUnit》
JDepend 设计质量指标:
- 类和接口的数量。包中具体类和抽象类(包括接口)的数量,代表了该包的可扩展性。
- 输入耦合度(Ca)。有多少其他的包依赖于该包中的类,表示了该包的职责范围。
- 输出耦合度(Ce)。该包中的类依赖于其他包的数量,表示了该包的独立度。
- 抽象性(A)。包中所有抽象类(包括接口)的数量,占包中所有类数量的比率。
- 不稳定性(I)。输出耦合度占总耦合度的比率,I = Ce/(Ce + Ca)。该指标表示该包对变化的适应能力。
- 与主序列的距离。某个包与理想线 A + I = 1 的垂直距离。该指标表示该包在抽象性和稳定性之间的平衡程度。
- 包依赖循环。如果包的依赖之间形成了循环,会生成其中各个包的层级路径报告。
- 设计质量指标
- 类和接口的数量
- 输入耦合度
- 输出耦合度
- 抽象性
- 不稳定性
- 与主序列的距离
- 包依赖循环
API
Mock
UT
前端测试体系
E2E
UT
Android 测试体系
官方指南:《Build effective unit tests》
分类 | 框架 | 覆盖范围 | 是否依赖设备 | 执行速度 |
---|---|---|---|---|
大型测试 | Appium, UIAutomator* | 用户通过界面操作的流程(涉及多应用和系统 UI 交互) | 是 | 慢,分钟级(一般在 1 ~ 5 分钟内,依测试场景复杂度而定) |
中型测试 | JUnit,Instrumentation | 功能测试:用户通过界面操作的流程(只能在单个应用内操作);集成测试:Java 方法(依赖 Android 框架、数据库、第三方能力实现) | 是 | 较慢,涉及界面操作的在分钟级(一般在 0.5~3 分钟,和同样操作步骤的界面测试相比,单个测试用例执行时间要少 40%);较快,不涉及界面操作的 Java 方法的测试在秒级(一般在 1 秒内,依被测方法的执行时间而定) |
小型测试 | JUnit,Mockito,Robolectric | “纯”Java 方法(不依赖 Android 框架、数据库、第三方能力,或这些依赖可以很方便的 Mock,对代码可测试性要求较高) | 否 | 快,毫秒级 |
类型:
- 本地测试
- JUnit
- Mockito
- Powermock
- Robolectric
- 插桩测试
- hamcrest
- espresso
- uiautomator
- E2E
- Calabash
- Robot Framework
- Appium
相关资源:
iOS 测试体系
- UiAutomation
- XCTest
- Frank
- KIF
- Kiwi
性能和压力测试
Apache Benchmark
Apache Benchmark:Ab
SuperBenchmarker(Windows 版的 Apache Benchmark): SuperBenchmarker
示例:
$ ab -n 10 -c 2 https://devops.phodal.com/
Gatling
Gatling:Gatling
安装:https://gatling.io/docs/current/installation
自动化部署应用
K8S + Dockerfile
非镜像的自动化方案
指标
Eclipse MicroProfile
Eclipse MicroProfile 是一个微服务的基准平台定义,针对微服务架构优化企业 Java,并为跨多个 MicroProfile 运行环境提供应用程序可移植性。
Eclipse Microprofile Metrics:Eclipse Microprofile Metrics
MicroProfile OpenTracing:MicroProfile OpenTracing
TBC
Dropwizard Metrics
GitHub: https://github.com/dropwizard/metrics
Spring Boot Actuator
Spring Boot Actuator:Spring Boot Actuator
引入监控
监控,观察并记录系统状态变化和数据流的过程。
StatsD + Graphite + Grafana
digraph {
subgraph stats {
uWSGI -> StatsD;
Logstash -> StatsD;
Diamond -> StatsD;
App1 -> StatsD;
App2 -> StatsD;
}
StatsD -> Graphite -> Grafana;
}
- Statsd 是一个使用 Node 开发网络守护进程,它的特点是通过 UDP(性能好,及时挂了也不影响主服务)或者 TCP 来监听各种数据信息,然后发送聚合数据到后端服务进行处理。
- Graphite 是一套 Python 写的开源编程接口,主要是用来收集服务器的及时状态,在这里主要作为 statsd 的数据后端。分为了三个子项目
- carbon 守护进程,接收 StatsD 发送过来的原始统计数据。
- whisper 用来存储统计数据的时间序列数据库。
- graphite webapp 用来图形化展示统计数据的 web 项目。
- Grafana 使用 Go 开发,可以在界面上设计调整自己的统计图表,支持多重报警,可定制化。
Java
Kamon
Docker 镜像:StatsD + Graphite + Grafana 4 + Kamon Dashboards
Python
日志收集和存储
Java
记录工具:
SLF4J:SL4J
Apache Log4J 2:Log4J 2
异常处理
Airbrake
请求跟踪
Java
OpenZipkin:https://zipkin.io/
Spring Cloud Sleuth:https://spring.io/projects/spring-cloud-sleuth
OpenCensus:OpenCensus
Prometheus
Prometheus 是用于事件监视和警报的免费软件应用程序。它将实时指标记录在使用 HTTP 拉模型构建的时间序列数据库中,并具有灵活的查询和实时警报。
ELK
示例架构:
digraph {
rankdir=LR;
APP1 -> Kafka;
APP3 -> Kafka;
APP4 -> Kafka
Kafka -> Logstash;
Logstash -> ElasticSearch -> Kibana;
}
ElasticSearch + Logstash + Kibana
安装见: https://www.elastic.co/start
Kafka + Flink
Flink:Flink Downloads
Flink 中文:Flink 下载
Kafka:Kafka Quickstart
追踪问题
第一次 Showcase
实施落地
主干开发
从发布倒推分支策略
特性开关
特性开关(Feature Toggle)是一种允许控制线上功能开启或者关闭的方式,通常会采取配置文件的方式来控制。当我们需要 A 功能的时候,我们就只需要把 A 功能的开关打开。当我们需要 B 功能,而不需要 A 功能的时候,我们就可以把相应的功能关掉。
缩小批次规模
——《DevOps 实施手册》
- 缩短周期时间
- 降低交付风险
- 降低集成风险
- 降低架构复杂性
- 提高测试质量
- 减少过度开发
- 减少浪费
- 降低可见性复杂度
- 改善环境
- 改善流程
- 改善文档
- 实现持续改善
对应的挑战:
- 人员。跨职能团队
- 流程。
- 小规模的、频繁的开发与测试、组件交付
- 对流程进行持续改善
- 架构。微架构
- 工具。减少非自动化步骤
微架构
后端:微服务
前端:微前端
APP:基座化
插件化
实施之后
回顾和总结
输出
回顾总结
规模化 DevOps 落地
DevOps 能力中心
建设框架
- 招募种子
- 明确目标、职责
- 组织内提供种子候选人
- 训战:专项培训
- DevOps 知识体系
- DevOps 实践
- 训战:项目实战
- 模拟项目
- 真实项目
- 训战:辅导分享
- 守
- 破
- 离
- 答辩评估
- 能力认证
- 认证通过
- ""
DevOps 内部教练
DevOps 平台
见:<a href="/practise/devops-platform" target="_blank">DevOps 平台</a>
DevOps 知识平台
Google DevOps 文档
DevOps 是一项组织和文化运动,旨在加快软件交付速度,提高服务可靠性,并在软件利益相关方之间建立共享所有权。了解如何提高软件交付的速度、稳定性、可用性和安全性。
Google 示例:Google DevOps
- Google DevOps
- DevOps 技术
- 版本控制
- 持续集成
- 部署自动化
- 主干开发
- 测试自动化
- 架构
- 赋予团队选择工具的能力
- 测试数据管理
- 更早将安全性纳入软件开发流程
- DevOps 流程
- 团队实验
- 简化变更审核流程
- 客户反馈
- 价值流中工作的可视性
- 小批量工作方式
- DevOps 衡量
- 监控系统以制定明智的业务决策
- 主动式故障通知
- 进行中工作数限制
- 目视管理
- DevOps 文化
- 工作满意度
- Westrum 组织文化
- 学习文化
- 如何进行转型
自下而上优化
成熟度模型的模式
附录:可信软件系统 10 要素
原文:《构建可信软件系统》
- 清晰可见的架构远景
- 架构设计原则
- 架构的多层级可视化
- 可信的软件安全策略
- 零信任的安全策略
- 高度自动化的工作流
- 开发工作流可视化
- 开发工作流自动化
- 风格受限的规范实践
- 时间表
- 设计架构适应度
- 设计架构适应度
- 高效的测试策略
- 测试模式
- 测试策略
- 更好的知识传递
- 文档代码化
- 组织内部分享知识
- 不止于代码的代码检视
- 框架与模块的与时俱进
- 主框架的更新节奏
- 时时更新辅助依赖
- 边界限定的系统架构
- 组合优于复合
- 配层,而非被接口适配
- 分层架构的二次分层
- 划分边界
- 持续偿还的技术债务
- 技术债务头脑风暴
- 可视化技术债务
- 可视化技术债务
- 强有力的个人 & 愿意改进的团队
- 提升个人能力
- 团队能力
- 团队多样性
来源:oschina
链接:https://my.oschina.net/huawenyao/blog/4311362