《持续交付发布可靠软件的系统方法》读书笔记
基础篇
第一章：软件交付的问题
第二章：配置管理
第三章：持续集成
第四章：测试策略的实现
部署流水线
第五章：部署流水线解析
第六章：构建与部署的脚本化
第七章：提交阶段
第八章：自动化验收测试
第九章：非功能需求的测试
第十章：应用程序的部署与发布
交付生态圈
第十一章：基础设施与环境管理
第十二章：数据管理
第十三章：组件和依赖管理
第十四章：版本控制进阶
第十五章：持续交付管理
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Michael Blog！
相关推荐
2020-05-20
持续交付发布可靠软件的系统方法（部署流水线）第十章：应用程序的部署与发布
《持续交付发布可靠软件的系统方法》读书笔记 引言发布到生产环境和部署到测试环境的差异应该被封装在一组配置文件中，遵循一样的部署过程。启动自动部署系统，将要部署的软件版本与环境名称告诉它，点击开始，后缀部署与发布使用相同的流程。我们需要有一个列表，其中包含能够部署到每个环境的所有构建，并且只要通过点击就可以选择一个软件版本向某个环境进行自动部署。同时这种方式是对环境修改的唯一途径（包括对操作系统和第三方软件配置的修改）。 创建发布策略（文档） 每个环境的部署由发布由谁负责 创建一个资产和配置管理策略 部署时所用的技术的描述。运维团队与开发团队应对其达成共识 实现部署流水线的计划 枚举所有的环境，包括用于验收测试、容量测试、集成测试、用户验收测试的环境，以及每个构建在这些环境中的移动过程 描述在测试和生产环境中部署时应该遵循的流程，比如一个变更申请，及申请授权等 对应用程序的监控需求，包括用于通知运维团队关于应用程序相关状态的API和服务 讨论部署时和运行时的配置方法如何管理，以及它们与自动化部署流程是如何关联在一起的 描述应用程序如何与所有外部系统集成 如何记录日志详情，以便运维人...
2020-05-20
gogs创建用户
/opt/gogs/gogs admin create-user –name=root –password=123456 –admin=true --email=abc@123.com –config=/etc/gogs/conf/app.ini 123oc project cicd &&gogspodname=$(oc get pod | grep gogs | grep -v postgresql| awk '{print $1}')oc rsh $gogspodname /opt/gogs/gogs admin create-user --name=root --password=123456 --admin=true --email=abc@123.com --config=/etc/gogs/conf/app.ini
2020-05-20
持续交付发布可靠软件的系统方法（部署流水线）第五章：部署流水线解析
《持续交付发布可靠软件的系统方法》读书笔记 什么是部署流水线部署流水线是指软件从版本控制到用户手中这一过程的自动化表现形式。价值流图 产品可行性评估 产品探索 产品计划与评估 开发 最后测试与审核 发布 3天 1周 7天 10天 10天 10天 3天 7周 1周 2天 2小时 开发到发布的流水线：会有很多次构建通过这一流程走向最后的发布 流水线各个阶段：交付团队->版本控制库->构建和单元测试->自动化验收测试->用户验收测试->发布 一般而言，只要某个构建使这个流程任一阶段失败，都会停止，不会进入下一个阶段。 提交阶段【自动化测试（主要是单元测试），代码分析】 自动化验收测试阶段【功能与非功能测试】 手工测试阶段【对自动化测试的补充，探索性测试，集成测试等】 发布阶段【部署到生产环境或试运行环境】 最基本的部署流水线 部署流水线的相关实践 只生成一次二进制包。对于不需要编译的语言，二制包指的是所有源文件的集合。这些二进制包应保存在文件系统的某个位置，让流水线后续阶段能够轻松访问到，但不要放在版本控制库中。二进制...
2020-05-20
持续交付发布可靠软件的系统方法（基础篇）第一章：软件交付的问题
《持续交付发布可靠软件的系统方法》读书笔记 软件构成部分：可执行的代码、配置信息、运行环境、数据 不同环境下只进行一次编译 对环境的任何修改都应该作为配置信息管理，配置信息的更改都需要经过测试 如果运行环境需要修改，则修改后的环境也需要进行测试。环境包括：操作系统配置、应用程序依赖的软件集、网络配置及任何基础设置、外部系统 数据结构发生变化，同样需要经过测试 反馈流程：指完全以自动化的方式尽可能地测试每一次变更 创建可执行代码的流程 单元测试 质量检测：测试覆盖率以及其他与技术相关的度量项 功能测试验收 性能、有效性、安全性等非功能测试 探索性测试，给客户/最终应用演示 自动化测试反馈【commit阶段】 运行速度快 尽可能全面，75%代码库覆盖率 环境中立，相对生产环境简单廉价 如果出现问题，绝不发布【commit之后测试】 运行速度慢一些，适合并行执行 即使有些测试问题，也可以发布应用程序 运行环境尽可能与生产相同 不同版本、不同环境的配置放在版本控制中 开发人员都拥有自己的专属开发环境 无论部署在什么目标环境都应采用同一种部署方法 开发环境是特例，可以有多...
2020-05-20
Mysql瓶颈分析方法
数据库往往会成为应用的最终瓶颈，而Mysql是被使用得最多的开源关系型数据库。如何分析执行Mysql数据库语句的性能就非常重要。但是很多开发人员并没有相关的意识与能力，但其实掌握了一些简单的常用手段，就可以让我们自己分析出数据库语句的问题。曾经看到过有对数据库查询语句中出现7个Select的语句，当时完全被震惊到了，这根本就是往系统里注入了一个大雷呀，数据量一旦增多，数据库挂，应用挂，服务挂，客户挂，公司挂。。。。还是不做破了一个鸡蛋就想着毁了一个养鸡场的推断了。我们收集下常见的数据库的分析手段。 查看当前数据库执行命令 12mysql> select count(*) from information_schema.processlist where COMMAND != 'Sleep';mysql> select * from information_schema.processlist where COMMAND != 'Sleep' limit 5; 慢查询查看慢查询时间定义 12345678910mysql&g...
2020-05-20
持续交付发布可靠软件的系统方法（交付生态圈）第十二章：数据管理
《持续交付发布可靠软件的系统方法》读书笔记 应用程序可以通过删除前一个版本，使用新版本替换旧版本的方式部署，但是大多数系统，数据无法使用这种方式进行变更，一旦某个系统发布到了生产环境中，关联的数据将不断增加。数据往往是系统中最有价值的部分。当我们需要对数据系统进行结构修改或者内容修改时，就需要相关的策略。对数据的修改是不可避免的，关键在于将数据迁移过程自动化。目前有一些工具对数据迁移提供了较多支持，它们还允许对数据库进行版本化管理。另一个重要部分是测试数据的管理。 数据库脚本化任何数据库的修改都应该通过自动化过程来管理。包括数据库的初始化，数据库所有的迁移都需要脚本化，并将脚本提交到版本控制库中。几乎所有的数据管理系统都支持通过自动化脚本进行数据存储的初始化工作。 清除原有的数据库 创建数据库结构、数据弯路实例以及模式等 向数据库加载数据 在大多数据项目中，数据库的使用要复杂得多。 增量式修改绝大多数据系统，对数据库更新时，要保留它们的数据。由于在部署时需要保留数据库中的已有数据，所以需要有回滚策略，以便部署失败时使用。这就需要对数据库进行版本控制。 在数据库中创建一个数据...