持续集成和DevOps基础

iTesting，爱测试，爱分享

正文

一、基本概念

1、持续集成

　　持续集成（Continuous integration，简称CI），简单来说持续集成就是频繁地（一天多次）将代码集成到主干。

　　每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。

　　持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，可以确定新代码和原有代码能否正确地集成在一起。

持续集成的好处：

• 快速发现错误，每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易；
• 防止分支大幅偏离主干，如果不经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

　　持续集成的目的：　　

让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

　　持续集成并不能消除 Bug，而是让它们非常容易的发现和改正。

2、持续交付

　　持续交付（Continuous delivery）指的是：频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

　　持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。

3、持续部署

　　持续部署（Continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。

　　持续部署的目标是：代码在任何时候都是可以部署的，可以进入生产阶段，持续部署的前提是能自动化完成测试、构建、部署等步骤。

4、持续交付和持续部署的区别

　　CD是持续交付和持续部署，但是持续交付不等于持续部署。持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。具体区别参考下图：

回到顶部

二、持续集成的一般流程

　　根据持续集成的设计，代码从提交到生产，整个过程有以下几步：

（1）提交

　　流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交（commit）。

（2）测试（第一轮）

　　代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。

（3）构建

　　通过第一轮测试，代码就可以合并进主干，就算可以交付了。

　　交付后，就先今夕构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。

　　常用的构建工具主要是：jeknins、Travis、codeship等。

（4）测试（第二轮）

　　构建完成，就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。

　　第二轮是全面测试，单元测试和继承测试都会跑，有条件的话，也要做端对端测试。所有测试以自动化为主，少数无法自动化的测试用例，就要人工跑。

（5）部署

　　通过第二轮测试，当前代码就是一个可以直接部署的版本（artifact）。将这个版本的所有文件打包（tar filename.tar *）存档，发到生产服务器。

　　生产服务器将打包文件，解包成本地的一个目录，再讲运行路径的符号链接（symlink）指向这个目录，然后重新启动应用。

　　这方面的部署工具有Ansible、Chef、Puppet等。

（6）回滚

　　一旦当前版本发生问题，就要回滚到上一个版本的构建结果。最简单的做法就是修改一下符号链接，指向上一个版本的目录。

回到顶部

三、认识DevOps

1、DevOps是什么？

　　DevOps 一词的来自于 Development（开发） 和 Operations（运维） 的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

　　目前对 DevOps 有太多的说法和定义，不过它们都有一个共同的思想：“解决开发者与运维者之间曾经不可逾越的鸿沟，增强开发者与运维者之间的沟通和交流”。

　　DevOps可以用一个公式表示：文化观念的改变+自动化工具 = 不断适应快速变化的市场。

强调：DevOps是一个框架，是一种方法论，并不是一套工具，它包括一系列的基本原则和实践。

DevOps的核心价值：

• 更快速地交付，响应市场的变化；
• 更多地关注业务的改进和提升。

2、为什么需要DevOps?

（1）产品迭代

　　在现实工作中，往往都是用户不知道自己想要什么，但是当我们设计完一个产品后，他会告诉我们他们不需要什么，这样我们的产品需要反复的迭代，而且过程可能是曲折的，那我们有什么好办法快速的交付价值，灵活的响应变化呢？

　　答案就是DevOps，因为DevOps是面向业务目标，助力业务成功的最佳实践。

（2）技术革新

　　现在的IT技术架构随着系统的复杂化不断的革新，从最初所有服务在一个系统中，发展到现在的微服务架构、从纯手动操作到全自动流程、从单台物理机到云平台。

3、DevOps如何落地？

落实DevOps的指导思想

高效的协作和沟通、自动化流程和工具、迅速敏捷的开发、持续交付和部署、不断学习和创新。

　　下面是一张来自 devops 经典著作《success with enterprise dev-ops whitepaper》的介绍图。

敏捷管理：一支训练有素的敏捷开发团队是成功实施DevOps的关键。

　　根据康威定律：软件团队开发的产品是对公司组织架构的反映。

　　持续交付部署：实现应用程序的自动化构建、部署、测试和发布。

　　通过技术工具，把传统的手工操作转变为自动化流程，这不仅有利于提高产品开发、运维部署的效率，还将减少人为因素引起的失误和事故，提早发现问题并及时地解决问题，这样也保证了产品的质量。下图展示了DevOps自动化的流程：

IT服务管理（ITSM），它是传统的“IT管理”转向为“IT服务”为主的一种模式，前者可能更关注具体服务器管理、网络管理和系统软件安装部署等工作；而后者更关注流程的规范化、标准化，明确定义各个流程的目标和范围、成本和效益、运营步骤、关键成功因素和绩效指标、有关人员的责权利，以及各个流程之间的关系等，比如建立线上事故解决流程、服务配置管理流程等；

精益管理：建立一个流水线式的 IT 服务链，打通开发与运维的鸿沟，实现开发运维一体化的敏捷模式。

　　精益生产主要来源于丰田生产方式（TPS）的生产哲学，它以降低浪费、提升整体客户价值而闻名，它主要利用优化自动化流程来提高生产率、降低浪费。所以精益生产的精髓是即时制（JIT）和自动化（Jidoka）。

　　精益管理贯穿于整个DevOps阶段，它鼓励主动发现问题，不断的优化流程，从而达到持续交付、快速反馈、降低风险和保障质量的目的。

4、实施DevOps的具体方法

（1）建立快速敏捷的团队

　　按照业务功能划分团队，建立沟通群组，设置产品负责人（一个策划人员）、Scrum Master（我们一般选择测试人员担任，测试驱动开发模式）和开发者团队（前端工程师、后端工程师、测试各一名），形成如下的组织结构和系统构架：

（2）实现自动化的流程

　　直接看图说话吧，以下为一个完整DevOps的Pipeline：

• 提交：工程师将代码在本地测试后，提交到版本控制系统，如Git代码仓库中。
• 构建：持续整合系统（如Jenkins CI），在检测到版本控制系统更新时，便自动从Git代码仓库里拉取最新的代码，进行编译、构建。
• 单元测试：Jenkins完成编译构建后，会自动执行指定的单元测试代码。
• 部署到测试环境：在完成单元测试后，Jenkins可以将应用程序部署到与生产环境相近的测试环境中进行测试。
• 预生产环境测试：在预生产测试环境里，可以进行一些最后的自动化测试，例如使用Appium自动化测试工具进行测试，以及与实际情况类似的一些测试可由开发人员或客户人员手动进行测试。
• 部署到生产环境：通过所有测试后，便可以使用灰度更新将最新的版本部署到实际生产环境里。

（3）DevOps在落地实施过程中经常会遇到的问题

　　人手紧缺；跨部门协作，前期沟通培训成本高；前期投入工作量大见效少。

5、DevOps技术栈

（1）敏捷管理工具

　　Trello、Teambition、Worktile、Tower

（2）产品&质量管理

　　confluence、禅道、Jira、Bugzila。

　　其中 confluence 和禅道主要是产品的需求、定义、依赖和推广等的全面管理工具；而 Jira 和 Bugzilla 是产品的质量管理和监控能力，包括测试用例、缺陷跟踪和质量监控等。

　　目前使用Jira 和 禅道较多。

（3）代码仓库管理

　　Git、Gitlab、Github.

　　Git是一个开源的分布式版本控制系统；

　　Gitlab 和 Github 是用于仓库管理系统的开源项目，它们使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

（4）自动化构建脚本

　　Gradle、Maven、SBT、ANT

（5）虚拟机和容器化　　

　　VMware、VirtualBox、Vagrant、Docker

（6）持续集成(CI)&持续部署(CD)

　　Jenkins、Hudson、Travis CI、CircleCI。

　　Jenkins 是一个开源软件项目，是基于 Java 开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能，它的前身为Hudson。

　　Travis CI 是目前新兴的开源持续集成构建项目，它与 jenkins 很明显的区别在于采用 yaml 格式，简洁清新独树一帜。

　　CircleCI 是一个 web 应用开发者提供服务的持续集成平台，主要为开发团队提供测试，持续集成，以及代码部署等服务。

（7）自动化测试

• Appium Appium是一个移动端的自动化框架，可用于测试原生应用，移动网页应用和混合型应用，且是跨平台的。可用于IOS和Android以及firefox的操作系统。
• Selenium Selenium 测试直接在浏览器中运行，就像真实用户所做的一样。Selenium 测试可以在 Windows、Linux 和 Macintosh上的 Internet Explorer、Mozilla 和 Firefox 中运行。
• Mock测试 Mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。这个虚拟的对象就是Mock对象，Mock对象就是真实对象在调试期间的代替品。Java中的Mock框架常用的有EasyMock和Mockito等。
• 消费者驱动契约测试 契约测试是一种针对外部服务的接口进行的测试，它能够验证服务是否满足消费方期待的契约。当一些消费方通过接口使用某个组件的提供的行为时，它们之间就产生了契约。这个契约包含了对输入和输出的数据结构的期望，性能以及并发性。而PACT是目前比较流的消费者驱动契约测试框架。

（8）自动化运维工具

• Ansible
• Puppet
• Chef

　　IT运维自动化是指将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，IT运维自动化不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。下图为常用自动化运维工具对比：

（9）监控管理工具

• Zabbix Zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级开源解决方案。
• ELK Stack日志分析系统 ELK Stack是开源日志处理平台解决方案，背后的商业公司是Elastic。它由日志采集解析工具 Logstash、基于 Lucene 的全文搜索引擎 Elasticsearch、分析可视化平台 Kibana三部分组成。
• 云监控（如Amazon CloudWatch） Amazon CloudWatch 是一项针对 AWS 云资源和在 AWS 上运行的应用程序进行监控的服务。您可以使用 Amazon CloudWatch 收集和跟踪各项指标、收集和监控日志文件、设置警报以及自动应对 AWS 资源的更改

注意：本内容转自休耕博客， 请点击阅读原文查看。

技术讨论

公众号里直接回复 666， 带你入圈。

- - 时人莫小池中水, 浅处不妨有卧龙 - -