DevopsPractice.md

1. Devops和持续交付

• 敏捷宣言
• DevOps核心目标：自动化和持续交互，增加人人互动
• DevOps工程师致力于让公司的流程更快，更有效，更可靠。只要有可能，就取代容易出错的重复劳动。

2. 洞察全局

• 开发 -> 版本控制，持续集成 -> 测试 -> 发布
  • 开发：提供两个或以上，持续维护，相互隔离的环境
  • 发布：预发布，切换老服务器 -> 蓝绿发布策略
• scrum, dashboard 和 CI
  • CI提供代码指标，辅助决策
  • CI部署通过代码配置
• 识别瓶颈

3. DevOps如何影响架构

• DevOps和持续交付着眼于软件架构的两个非功能性需求：
• 频繁交付更小的变更
• 对产品质量更有信心
• 架构经验法则：
  • 关注点分离：分开考虑系统的不同方面
  • 内聚原则： 内聚指软件内各模块之间相互关联的程度，模块内高内聚
  • 耦合： 两块模块间相互依赖的程度，模块间低耦合

（高内聚低耦合的系统自动关注点分离）

• 微服务：业务由许多小的服务组成，服务之间通信使用语言无关的协议
• 康威定律： 设计软件的组织结构，等价于软件的组织架构

4. 一切皆代码

• 分布式版本管理系统（DVCS，常用的Git）优势：

  • 不依赖互联网
  • 运行更快
  • 可以独立工作
  • 可以同时和多个远程环境协同工作

• 分支策略：描述应该合适创建分支，如何命名，分支应该如何使用等等的规则

  • 例如： GitFlow

    

  • 分支问题域: 提交修复到已发布的版本，而当前主干已经有新的功能

    • 创建一个缺陷修复分支并在该分支上部署生产环境：
      • 不会打断当前开发流程
      • 额外的测试资源开销
    • 功能开关：
      • 可以发布最新的开发版本，包括缺陷修复和暂时关闭的新功能
      • 对开发者要求严格

  (当更改主要是向下兼容或者是全新功能的时候，功能开关更优；缺陷修复分支更直观，但是需要额外的部署和测试资源)

• 版本命名基本原则

  • 单向递增
  • 可以相互比较
  • 所有项目使用相同的版本体系
    • 1. 主要代码变更
    • 2. 次要代码变更， API向后兼容
    • 3. 修复缺陷
    • 4. 构建号

  (参考：语义化版本号 SemVerion)

• LDAP服务器

• 大的二进制文件：

  • GitHub: Git LFS
  • GitLab: Git Annex

• 代码提交：

  • squashing：将一系列小的修改合并为一个提交
  • rebasing： 移除本地变更， 获取上游库变更， 重新应用本地变更， 避免上游库合并进入历史

5. 构建代码

• 构建服务器：Jenkins
• 依赖管理：Maven POM，RPM等等
• 持续集成：每个提交都进行集成测试
• 持续交付：持续部署最新组件
• 校验质量指标： Sonar
• 健壮性：构建本身应该尽可能健壮，并可以在任何主机上重复工作

6. 测试代码

• 人工测试（KISS： Keep it simple, stupid）
  • 管理测试数据
  • 尽快部署
• 自动化测试
  • 缺点
    • 廉价的测试没有什么价值（类似unit test，价值不是很高）
    • 创建测试框架困难
    • 程序功能变化，测试需要相应调整，耗费时间精力
    • 不同环境下编写可靠工作的健壮测试很困难
  • 测试类型
    • 单元测试
      • 与开发相关
      • 用于测试系统中与其他部分隔离，定义良好的部分
      • 容易编写和使用
      • mocking
    • 自动化集成测试
      • 和单元测试主要区别在于尽量使用生产系统减少mocking
    • 性能测试
      • 类生产环境系统
      • 负载
    • 自动化acceptance测试
      • 用户角度出发
      • 行为驱动开发
    • 自动化GUI测试
      • selenium
  • 测试驱动开发（TDD）
    • 实现测试：根据定义的接口，先写测试，然后写代码
    • 验证新写测试会失败
    • 编写实现测试的功能
    • 验证新旧测试都能通过
    • 重构代码
  • 交互式命令行（REPL）驱动开发
    • 常用语解释型语言，如Python， ruby， JS等
    • 读取，计算， 打印， 循环 （RELP）类型语言，编写小而独立的函数，且不依赖于全局的状态
    • 函数编写的时候就得到了测试

7. 部署代码

• 基础操作系统：实体机，虚拟机，AWS， Docker等
• 描述集群
• 为系统交付包：
  • 一定有一种方式为系统交付包
  • 必须有独立于安装包之外的配置管理的方式

8. 监控代码

• 监控已部署代码，如果出现问题，在最短时间内找到哪些地方出错并处理
• 代码服务器监控工具：
  • Nagios：监控所有服务器状态，包括主机状态（cpu，磁盘，挂起），网络情况等
  • Munin：收集服务器数据到RRD（轮询数据库 Round-robin Database），并绘图
  • Graphite：收集数据绘图，接近实时
• 日志处理：
  • ELK（Elasticsearch，Logstash，Kibana）
  • 不同日志优先级：Debug，Warning，Trace，Error
  • 日志轮替和归档
  • 日志过度会影响服务性能，日志过少无法帮助诊断失败的原因

9. 问题跟踪

• 帮助处理敏捷流程中的工作细目，缺陷和问题等
• 问题
  • 组成部分：
    • 描述：问题的描述
    • 报告者：谁创建了问题
    • 指派：应该工作在这个项目的人
  • 状态：
    • 打开
    • 进行中
    • 可测试
    • 测试中
    • 完成
    • 关闭
• 问题追踪器：
  • Bugzilla：常用与面向公网的问题报告工作
  • Trac：简单，集成，插件多
  • redmine
  • Jira

10. Devops和物联网