DevOps实践.png
第一章 DevOps和持续交付简介
- DevOps: 包含技术与非技术两方面，还包括动手能力和软技能。
DevOps = Developments + Opertions
基于软件工程的复杂性，在软件开发周期中，通常是有进行分工的（编码、测试、维护由不同人，不同组进行），然而这种分工（通常还伴随着收入差）造成了信息流通的不畅，信息不对称也就产生了。这种不对称必然造成原先的协作关系转换为对立关系，造成开发效率下降、软件质量下降，这显然背离软件开发的核心目标（抢占市场、增加商业价值）。DevOps就是针对上述症状的一剂药方。 - 敏捷软件开发宣言
a. 个体和互动高于流程和工具（DevOps核心）
b. 工作的软件高于详尽的文档
c. 客户合作高于合同谈判
d. 相应变化高于遵循计划 - DevOps核心目标
a. 强调个体和互动
b. 自动化和持续交付 - 敏捷不能流于形式 => Sprint回顾会议机制。
第二章 洞察全局（DevOps全流程概览）
- DevOps流程和持续交付
编码->版本控制->测试->运维
a. 开发预打包环境，包含JDK，IDE等（目标开箱即用）
b. 版本控制（软件开发的中心），Git
c. 构建服务器（持续集成），Jenkins
d. 工件库（存储二进制），Nexus
e. 包管理器（工具版本管理）
f. 测试（单元测试，集成测试，接受测试）
g. 预发布（蓝绿发布） - 发布管理
大量都是自动化工作，但是不可避免还是需要人工介入。
可通过Scrum，看板等支付流水线 - 完整的例子
第三章 DevOps如何影响架构
- 软件架构介绍
着眼于软件架构两个非功能需求：
a. 需要频繁交付小变更（小步快跑）
b. 需要对质量有大信心（质量保证） - 单块系统场景
整块部署，版本号管理 - 关注点分离
拆分系统最重要的原则 - 模块化：低内聚，高耦合的系统，需要改造
- 软件三层结构：表示层、业务层、数据层。
- 数据库迁移（自动化，Liquibase）
- 微服务
a.康威定律：设计软件的组织结构，等价于软件的组织结构。DevOps的目标是建立不同角色共同协作，跨职能团队。因此微服务会促进构建内聚高，功能单一的团队。而这正好契合了DevOps的目标，所以DevOps就和微服务紧密结合了。
b.服务接口向上兼容：Tolerant Reader模式，忽略无法识别的数据。
c.微服务和数据库：系统间隔离明显，部署就会简单，而隔离月不明显（揉合)，数据模型就会简单。所以，在微服务中，数据库的划分通常没有一个最优方案。 - DevOps架构和弹性
a. 复杂性：为了尽快部署，也要保证可靠，必然增加了大量的集成点，系统也更为复杂了，从概率上来说，失败的可能性就更高了。
b. 工具依赖性:为了解决上述矛盾，必然引入自动化测试，自动化部署，自动化监控等一系列工具，从而对工具的依赖也大大加强了。
第四章 一切皆代码
- 源代码控制的必要性
a. 源代码管理历史: tar包、集中式、并发集中式、去中心分布式
b. 角色与代码：开发（无需多言，饭碗）、运维（脚本生成、网络拓扑）、质量保证（自动化测试脚本） - 源代码管理选型
目前大势就是Git：
a. 迁移：大部分工作用在保持历史记录的完整性，而大部分企业并不关心这个。
b. 分支策略：不是自己独立工作、团队协作才有意义；Git Flow
c. 分支问题域：新功能，问题修复，版本控制。如果针对缺陷专门定制修复分支，对其单独修复、部署就有可能引起合并冲突，而如果在现有新功能上增加功能开关，又会增加开发工作量，并引入额外的管理工作。
d. 工作版本号命名：不推荐用快照版本命名方式
e. 客户端选择：要么自建Git服务器，要么使用托管服务器
f. 大的二进制文件：mp4等视频->Git Annex
g. 不同的GIt服务器实现：Gerrit、GitLab
第五章 构建代码
- 构建代码:
a. 过程：编译、静态分析、单元测试、生成可部署产品
b. 数量众多：每种语言都有好几种构建工具
c. 目标： 一个开发者签出代码，应该能够在他本地开发机顺利地构建。 - Jenkins介绍：
- 管理构建依赖： Maven、RPM、Deb
- 最终工件：
对于Java来说，就是生成可以部署的EAR，而对于其它语言，可能是二进制文件，而可能是特定的格式文档（shell、HTML、js） - 用FPM取巧：
命令行构建源代码RPM包 - 持续集成：
用来测试把多个系统的变更统一在一个环境，测试其能否正常交互工作。 - 持续交付
- Jenkins插件，Jenkins从机
- 质量保证：Sonar
（好杂乱的一章，没了解Jenkis根本跟不上）
第六章 测试代码
- 人工测试
a. 人工测试依然是软件开发中一个重要部分，特别是接受测试，必须有测试人员介入。
b. 为了测试人员开心：要求管理测试数据（DB可恢复），并且能尽快部署 - 自动化测试优缺点：
a. 单元测试成本低、价值低、可能认为人工测试的实践动作能暴露更多的BUG（测试人员抵触）
b. 创建自动化集成测试支架（Test cradle）较困难（技术能力）
c. 程序随时间变化功能变化、测试必须同步维护（成本高，开发人员抵触）；一个敏捷团队对自己服务的成功、维护、中断负有全部责任。
d. 编写可靠工作的健壮测试很难（人员要求高）
e. 写自动化测试难（本身技术复杂）
中国公司不重视测试时有原因的，这些要素叠加的结果就是，如果要求大量自动化测试，比如增加开发人员工作量，降低单位时间产出，而中国人力成本便宜，为什么不用堆人的人工测试呢？ - 单元测试：
a. 区分单元测试、功能测试。如果测试需要进行复杂设置和运行时依赖，那么它就是功能测试。
b. Junit概念：Test Runner、Test Case、Test Fixtures、Test Suites、Test Execution、 Test Result Formatter、Assertions
c. Mock: Mockito
d. 测试覆盖率： Cobertura、Clover - 自动化集成测试：
较少Mock的测试，尽量模拟真实的生产环境。
a. 使用Docker模拟
b. Arquilian
c. 性能测试 Jmeter - 自动化接受测试： BDD，先写一个Spec，再进行编码（我的天，这么搞，把人折腾的）
- 自动化UI测试： Selenium
- 测试驱动开发： TDD
- 一个实例
第七章 部署代码
重点关注二进制数据包以及配置管理系统安装它们的配置。
- 为什么有那么多部署系统：场景复杂，一个企业级应用，比如有多套不同类别的服务需要管理：
Web服务器、应用服务器、数据库、不同操作系统。 - 配置基础OS：Coller、docker。
- 描述集群：
- 系统交付包：推荐基于文件的配置管理系统（例如spring cloud config）
- 虚拟化栈：
VMware、KVM、Xen、VirtualBox - 一些部署工具：
Puppet、Ansible、PalletOps、Chef、SaltStack - 云计算：Aws、Azure（国内阿里云，腾讯云）
第八章 监控代码（监控系统）
- Nagios：始于1994年，用于监视主机状态。
- Munin：统计数据
- Ganglia：图片看似不错，不过2016年以后无新版本
- Graphit：实时绘图(Jhipster有用它)
a. Graphit Web：仪表盘界面
b. Garbon：收集指标的后台进程
c. Whisper：时间序列的数据库类库 - 日志分析系统：log4j -> ELK
第九章 问题跟踪器
- 工作流：
问题的基本属性：描述、报告者、指派、状态
问题的额外属性：到期日、里程碑、附件、工作量估计、额外状态 - 问题跟踪器选型考虑因素：
- 几个问题跟踪系统：Bugzilla、Trac、Redmine、GitLab、Jira
第十章 物联网和DevOps
这章基本是作者的私货，着重介绍物联网。
总结一下：
大致把DevOps涉及的部分介绍到了，对每个需要关注的地方做了一些分析，可能用到的工具也大致做了介绍。可是感觉作者思维跳跃太大，章节内部小知识点连贯性很差，前言不搭后语的，很难跟上节奏，读起来很累。总的来说，有一点收获吧
网友评论