DevOps实践

---

DevOps实践.png

第一章 DevOps和持续交付简介

1. DevOps: 包含技术与非技术两方面，还包括动手能力和软技能。
   DevOps = Developments + Opertions
   基于软件工程的复杂性，在软件开发周期中，通常是有进行分工的（编码、测试、维护由不同人，不同组进行），然而这种分工（通常还伴随着收入差）造成了信息流通的不畅，信息不对称也就产生了。这种不对称必然造成原先的协作关系转换为对立关系，造成开发效率下降、软件质量下降，这显然背离软件开发的核心目标（抢占市场、增加商业价值）。DevOps就是针对上述症状的一剂药方。
2. 敏捷软件开发宣言
   a. 个体和互动高于流程和工具（DevOps核心）
   b. 工作的软件高于详尽的文档
   c. 客户合作高于合同谈判
   d. 相应变化高于遵循计划
3. DevOps核心目标
   a. 强调个体和互动
   b. 自动化和持续交付
4. 敏捷不能流于形式 => Sprint回顾会议机制。

第二章 洞察全局（DevOps全流程概览）

1. DevOps流程和持续交付
   编码->版本控制->测试->运维
   a. 开发预打包环境，包含JDK，IDE等（目标开箱即用）
   b. 版本控制（软件开发的中心），Git
   c. 构建服务器（持续集成），Jenkins
   d. 工件库（存储二进制），Nexus
   e. 包管理器（工具版本管理）
   f. 测试（单元测试，集成测试，接受测试）
   g. 预发布（蓝绿发布）
2. 发布管理
   大量都是自动化工作，但是不可避免还是需要人工介入。
   可通过Scrum，看板等支付流水线
3. 完整的例子

第三章 DevOps如何影响架构

1. 软件架构介绍
   着眼于软件架构两个非功能需求：
   a. 需要频繁交付小变更（小步快跑）
   b. 需要对质量有大信心（质量保证）
2. 单块系统场景
   整块部署，版本号管理
3. 关注点分离
   拆分系统最重要的原则
4. 模块化：低内聚，高耦合的系统，需要改造
5. 软件三层结构：表示层、业务层、数据层。
6. 数据库迁移（自动化，Liquibase）
7. 微服务
   a.康威定律：设计软件的组织结构，等价于软件的组织结构。DevOps的目标是建立不同角色共同协作，跨职能团队。因此微服务会促进构建内聚高，功能单一的团队。而这正好契合了DevOps的目标，所以DevOps就和微服务紧密结合了。
   b.服务接口向上兼容：Tolerant Reader模式，忽略无法识别的数据。
   c.微服务和数据库：系统间隔离明显，部署就会简单，而隔离月不明显（揉合)，数据模型就会简单。所以，在微服务中，数据库的划分通常没有一个最优方案。
8. DevOps架构和弹性
   a. 复杂性：为了尽快部署，也要保证可靠，必然增加了大量的集成点，系统也更为复杂了，从概率上来说，失败的可能性就更高了。
   b. 工具依赖性:为了解决上述矛盾，必然引入自动化测试，自动化部署，自动化监控等一系列工具，从而对工具的依赖也大大加强了。

第四章 一切皆代码

1. 源代码控制的必要性
   a. 源代码管理历史: tar包、集中式、并发集中式、去中心分布式
   b. 角色与代码：开发（无需多言，饭碗）、运维（脚本生成、网络拓扑）、质量保证（自动化测试脚本）
2. 源代码管理选型
   目前大势就是Git：
   a. 迁移：大部分工作用在保持历史记录的完整性，而大部分企业并不关心这个。
   b. 分支策略：不是自己独立工作、团队协作才有意义；Git Flow
   c. 分支问题域：新功能，问题修复，版本控制。如果针对缺陷专门定制修复分支，对其单独修复、部署就有可能引起合并冲突，而如果在现有新功能上增加功能开关，又会增加开发工作量，并引入额外的管理工作。
   d. 工作版本号命名：不推荐用快照版本命名方式
   e. 客户端选择：要么自建Git服务器，要么使用托管服务器
   f. 大的二进制文件：mp4等视频->Git Annex
   g. 不同的GIt服务器实现：Gerrit、GitLab

第五章 构建代码

1. 构建代码:
   a. 过程：编译、静态分析、单元测试、生成可部署产品
   b. 数量众多：每种语言都有好几种构建工具
   c. 目标： 一个开发者签出代码，应该能够在他本地开发机顺利地构建。
2. Jenkins介绍：
3. 管理构建依赖： Maven、RPM、Deb
4. 最终工件：
   对于Java来说，就是生成可以部署的EAR，而对于其它语言，可能是二进制文件，而可能是特定的格式文档（shell、HTML、js）
5. 用FPM取巧：
   命令行构建源代码RPM包
6. 持续集成：
   用来测试把多个系统的变更统一在一个环境，测试其能否正常交互工作。
7. 持续交付
8. Jenkins插件，Jenkins从机
9. 质量保证：Sonar
   （好杂乱的一章，没了解Jenkis根本跟不上）

第六章 测试代码

1. 人工测试
   a. 人工测试依然是软件开发中一个重要部分，特别是接受测试，必须有测试人员介入。
   b. 为了测试人员开心：要求管理测试数据（DB可恢复），并且能尽快部署
2. 自动化测试优缺点：
   a. 单元测试成本低、价值低、可能认为人工测试的实践动作能暴露更多的BUG（测试人员抵触）
   b. 创建自动化集成测试支架（Test cradle）较困难（技术能力）
   c. 程序随时间变化功能变化、测试必须同步维护（成本高，开发人员抵触）；一个敏捷团队对自己服务的成功、维护、中断负有全部责任。
   d. 编写可靠工作的健壮测试很难（人员要求高）
   e. 写自动化测试难（本身技术复杂）
   中国公司不重视测试时有原因的，这些要素叠加的结果就是，如果要求大量自动化测试，比如增加开发人员工作量，降低单位时间产出，而中国人力成本便宜，为什么不用堆人的人工测试呢？
3. 单元测试：
   a. 区分单元测试、功能测试。如果测试需要进行复杂设置和运行时依赖，那么它就是功能测试。
   b. Junit概念：Test Runner、Test Case、Test Fixtures、Test Suites、Test Execution、 Test Result Formatter、Assertions
   c. Mock: Mockito
   d. 测试覆盖率： Cobertura、Clover
4. 自动化集成测试：
   较少Mock的测试，尽量模拟真实的生产环境。
   a. 使用Docker模拟
   b. Arquilian
   c. 性能测试 Jmeter
5. 自动化接受测试： BDD，先写一个Spec，再进行编码（我的天，这么搞，把人折腾的）
6. 自动化UI测试： Selenium
7. 测试驱动开发： TDD
8. 一个实例

第七章 部署代码

重点关注二进制数据包以及配置管理系统安装它们的配置。

1. 为什么有那么多部署系统：场景复杂，一个企业级应用，比如有多套不同类别的服务需要管理：
   Web服务器、应用服务器、数据库、不同操作系统。
2. 配置基础OS：Coller、docker。
3. 描述集群：
4. 系统交付包：推荐基于文件的配置管理系统（例如spring cloud config）
5. 虚拟化栈：
   VMware、KVM、Xen、VirtualBox
6. 一些部署工具：
   Puppet、Ansible、PalletOps、Chef、SaltStack
7. 云计算：Aws、Azure（国内阿里云，腾讯云）

第八章 监控代码（监控系统）

1. Nagios：始于1994年，用于监视主机状态。
2. Munin：统计数据
3. Ganglia：图片看似不错，不过2016年以后无新版本
4. Graphit：实时绘图(Jhipster有用它)
   a. Graphit Web：仪表盘界面
   b. Garbon：收集指标的后台进程
   c. Whisper：时间序列的数据库类库
5. 日志分析系统：log4j -> ELK

第九章 问题跟踪器

1. 工作流：
   问题的基本属性：描述、报告者、指派、状态
   问题的额外属性：到期日、里程碑、附件、工作量估计、额外状态
2. 问题跟踪器选型考虑因素：
3. 几个问题跟踪系统：Bugzilla、Trac、Redmine、GitLab、Jira

第十章 物联网和DevOps

这章基本是作者的私货，着重介绍物联网。

---

总结一下：
大致把DevOps涉及的部分介绍到了，对每个需要关注的地方做了一些分析，可能用到的工具也大致做了介绍。可是感觉作者思维跳跃太大，章节内部小知识点连贯性很差，前言不搭后语的，很难跟上节奏，读起来很累。总的来说，有一点收获吧