2.DevOps

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

2.1 DevOps降低应用发布的风险

在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下：
（1）减少变更范围
与传统的瀑布模式模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。由此可见，敏捷开发与DevOps是天作之合：用于敏捷开发，DevOps才能体现其价值；采用DevOps的管理方法，敏捷开发才能真正敏捷起来。
（2）加强发布协调
靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议和企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。
（3）自动化
强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。

2.2 持续集成

持续集成是敏捷交付实践的关键组件。它是一种DevOps软件开发实践，在这个过程中，代码的更改在测试后定期合并到一个中央库中。持续集成的主要目的是更快地查找并修复潜在问题，提高软件质量，并且缩短发布新的更新的时间。

在持续集成实践广泛应用之前，开发人员一般以孤立的方式编写代码，在个人的工作完成后，仅尝试将更改合并到主分支中。这种将多个代码拼凑在一起的方法使得合并极为困难，而且非常耗时。

通过持续集成，开发人员可以频繁地向中央库分享，在集成前对代码进行本地的单元测试。持续集成服务器然后自动测试开发人员编写的代码，以保证代码可以合并到主代码库中，而不会出现任何功能或集成错误。通过自动执行这个流程，服务器可帮助开发人员几乎连续编写并测试少量代码，这最大程度降低了严重错误出现的风险。

常用的持续集成工具有：JenKins、Bamboo

2.3 持续交付

持续交付是在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。持续交付理念最早来源于敏捷，意为尽早持续交付有价值的软件让客户满意，提前并且频繁地做让你痛苦的事情（以降低风险）。通俗来讲，持续交付要实现这样一个目标：产品团队具备通过重复、可靠的研发过程（自动化），采取小批量频繁的部署或发布，尽可能早地获取质量反馈，使版本快速达到随时可交付状态。

实施持续交付的主要措施：
1、“小批量/小粒度频繁的持续部署或发布”；
2、“为软件的开发到发布创建一个可重复且可靠的自动化过程”；
3、“每次修改都能经过一次构建、测试、部署、发布完整高效的自动化验证过程，实现高速频繁验证，快速问题闭环”。

2.4 持续部署

持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。

持续交付和持续部署两者都简称CD，有些人将两者互用，但二者有明显的区别，需要明确理解和认识。持续交付是指几乎连续地向用户发布更新，然而，这些更新必须由DevOps团队手动发布。与此相反，持续部署管道则完全自动运行。这样，用户能够在编写和测试代码后尽快收到更新，而不必等待开发人员的手动干预。所需的任何测试在类生产环境中进行，并且在合并到主线分支之前完成。

随着Docker等技术使得应用部署自动化更加轻松，持续交付和持续部署的区别肯定会越来越重要。这种易用性允许DevOps团队将容器镜像放到生产环境中，让其自动部署。这种自动化流程是持续交付的关键，因为这个流程可由任何人在几分钟内完成。

2.5 DevOps工程师

在团队向DevOps转型时，需要有一个角色去弥合软件开发和运营团队之间的差距，需要重点关注自动化和持续集成，这个角色就是DevOps工程师。DevOps工程师是指一名内部技术人员，经过培训或学习，能够以经济高效的方式将DevOps实践应用到IT组织中。

不幸的是，好的DevOps工程师很难找到。 DevOps工程师现在在美国已是排名第二的热门职位，而且目前业界关于该职业的争议也导致DevOps工程师对于什么应该做，什么不应该做这件事没有一个明确的界限点。

有些DevOps工程师可以一个人担负起监督IT部门整个DevOps流程的转换，甚至包括文化方面的转换，但有些DevOps工程师只是可以管理实行DevOps生命周期的一些特定阶段的工具，比如Jenkins，Maven和Ant等特定工具。

因此，公司必须非常具体地了解你所聘用的DevOps工程师能够做什么。否则很容易最后发现自己冒险地雇用了一些可能无法通过预期的人。

上一篇：敏捷开发、DevOps和云计算（六）下一篇：敏捷开发、DevOps和云计算（八）