|
|
|
DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。维基百科中关于DevOps的定义是“DevOps是一组过程、方法与系统的统称，用于促进开发、运维和质量保障（QA）部门之间的沟通、协作与整合。”它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。
|
|
|
|
|
|
传统运维的一种极端情况可以被描述为“黑盒运维”。在这种文化中，运维与开发是分开的，相互间一般不合作，就算合作，也是极为不情愿的。其特点就是开发和运维有着相反的目标。开发团队的任务是为产品增加新功能、不断升级产品，并以此制定绩效。运维团队的目标，则是稳定第一。如果没有进行足够的沟通交流，两个团队就会产生矛盾，当开发人员兴致勃勃的快速开发新功能的时候，运维人员可没什么心情去部署新功能。对稳定系统实施任何类型的变更，都会导致系统产生隐患，因此运维人员会尽可能避免变更。产生这种鸿沟的原因如下。
|
|
|
|
（1）开发人员经常不考虑自己写的代码会对运维造成什么影响，他们在交付代码之前，并不邀请运维人员参与架构决策或代码评审。
|
|
|
|
（2）开发人员对配置或环境进行修改之后，经常没有及时与运维人员沟通，导致新的代码不能运行。
|
|
|
|
（3）开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤，想找到必要的配置参数，通常需要尝试很多不同的参数。
|
|
|
|
（4）开发人员倾向于使用有利于快速开发的工具，这样的工具集与运营人员面对的目标运行时环境非常不同（后者对稳定性和性能的要求远胜于灵活性）。
|
|
|
|
（5）开发人员平时使用桌面电脑，他们倾向于使用为桌面用户优化的操作系统，生产环境系统通常都运行在服务器操作系统上。
|
|
|
|
DevOps需要在组织内部进行文化和技术的改变。从团队文化角度来说，运维和开发的传统思维需要改变，这样才能更开诚布公的进行沟通，实现目标的统一。从技术角度来讲，开发人员需要了解运维团队的工作方式，并加深对系统架构的认识。运维人员需要明白开发流程，并深入了解代码内容。
|
|
|
|
|
|
（1）基础架构即代码。基础架构即代码（IaC）是大部分通用DevOps实践的前提要求，这一概念涉及计算基础架构（虚拟机、网络、软件安装等）的管理和供应，以及通过机器可处理的定义文件或脚本对其进行自动配置，交互式配置工具和手工命令的使用已经不合时宜了。通过代码表示环境的相应状态，以免手动配置环境，同时确保一致性。通过代码实现的基础结构部署是可重复的，从而快速、可靠、大规模地交付应用程序及其支持基础结构。
|
|
|
|
借助基础结构即代码，可以在开发周期的早期在类似生产的环境中测试应用程序。这些团队希望按需预配多个可靠的测试环境。还可以验证和测试表示为代码的基础结构，以防出现常见的部署问题。
|
|
|
|
（2）持续交付。持续交付是一种可以帮助团队以更短的周期交付软件的方法，该方法确保了团队可以在任何时间发布出可靠的软件。该方法意在以更快速度更高频率进行软件的构建、测试和发布。通过对生产环境中的应用程序进行更高频次的增量更新，这种方法有助于降低交付变更过程中涉及的成本、时间和风险。足够简单直接并且可重复的部署流程对持续交付而言至关重要。
|
|
|
|
（3）协作。DevOps文化的主要特征在于开发和运维角色之间日益增加的协作。这是一种在团队内部以及组织层面上很重要的文化变迁，通过这样的变迁才能促进更好的协作。
|
|
|
|
|
|
|
|
（1）产品高效交付：DevOps理念指向“高度的自动化”，试图制定一条从开发到运维的流水线，最大限度地摆脱人工的束缚。
|
|
|
|
（2）改善公司组织文化、提高员工的参与感。员工们变得更高效，也更有满足和成就感。
|
|
|
|
|
|
DevOps希望做到的是软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。DevOps需要的工具主要分3类。
|
|
|
|
（1）版本控制软件库。它可以确保所有系统产品在整个版本发布生命周期中被很好地定义，并且能够实现一致性共享，同时保持最新信息。开发和QA机构能够从中取得相同平台版本，生产机构部署已经被QA机构验证过的相同版本。
|
|
|
|
（2）深层模型系统。它的版本系统清晰地描述了软件系统相关的所有组件、策略和依赖性，从而可以简单地根据需要复制一个系统或在无冲突的情况下引入变化。
|
|
|
|
（3）人工任务的自动化。在依赖关系发现、系统构造、配置、更新和回滚等过程中减少人工干涉。自动操作变为高速、无冲突和大规模系统管理的命令和控制基础。
|
|
|
|
在从开发到运维的生命周期中存在许多不同的工具，工具选择需要结合公司业务需求和技术团队情况而定。
|
|
|
