关于devops:什么是DevOps

7次阅读

共计 2403 个字符,预计需要花费 7 分钟才能阅读完成。

原文链接:https://support.huaweicloud.com/reference-devcloud/devcloud_r…

DevOps 概述

DevOps,即Development and Operations,是一组过程、办法与零碎的统称,用于促成软件开发、运维和品质保障部门之间的沟通、合作与整合。DevOps 的呈现是因为软件行业日益清晰的意识到:为了按时交付软件产品和服务,开发和运维工作必须严密单干。DevOps 可看作开发、运维和品质保障(QA)三者的交加。

DevOps 静止 源自于进步 IT 服务交付敏捷性的须要,晚期呈现在许多大型私有云服务提供商中,并被其认可。撑持 DevOps 的理念根底是 麻利宣言,它强调人(和文化),致力于改善开发和运维团队之间的合作。从生命周期的角度来看,DevOps 的实施者也试图更好的利用技术,尤其是自动化工具,来撑持越来越多的可编程的动静的基础设施。

DevOps 的技术实际

  • 配置管理

    软件配置管理的外围性能是版本控制。版本控制系统是一种软件,能够治理代码的所有版本并跟踪代码中的更改。

    • 分布式 Git VS 集中式 SVN

      版本控制系统分为集中式和分布式两种工作模式,Git 和 SVN 是最为宽泛被应用的代表,Git 因为其诸多特点,更适宜 DevOps。

      • 安全性——Git 是分布式,而 SVN 是集中式,存在单点故障危险。
      • 分支性能——Git 分支功能强大,便于查问和追溯分支间的提交历史,且反对双向合并。
      • 公布管制——Git 公布管制相当灵便,而 SVN 并没有明确的公布管制配置。
      • 开发审核——Git 反对团队成员自建分支和版本库,从提交阐明、代码标准等方面对提交逐个审核;而 SVN 则不具备这些性能。
      • 合并反对——Git 基于 DAG(有向非环图)的设计比 SVN 的线性提交提供更好的合并追踪,防止不必要的抵触,进步了工作效率。
      • 存储形式——Git 把内容按元数据形式存储,而 SVN 是按文件。
    • 包文件

      包文件通常不放在源码库中治理,而是应用专门的包文件仓库(repository)进行存储,并配合包文件依赖管理工具(Maven、npm、Ivy 等)进行应用。包文件仓库能够大抵分为本地仓库、私服仓库、地方仓库三种。本地仓库是指开发者集体 PC 中包文件的存储;私服仓库通常是企业为了晋升包文件使用性能而搭建的局域网内共用的包文件仓库,通常应用开源的 Nexus、artifactory 等工具搭建;地方仓库是指开源包文件的共享社区。

      开发人员对包文件的应用集中在下载、搜寻、公布上传几个操作上。开发和构建时,开发人员通过包依赖管理工具定义好须要应用的公有及开源包文件,在构建或运行时主动从私服仓库或开源地方仓库中下载依赖包文件来晋升开发效率。

  • 继续集成(Continuous Integration)

    继续集成(CI)是一种软件开发实际,即团队的成员常常集成他们的工作,通常每个成员每天至多集成一次——这导致每天产生屡次集成。每次集成都通过自动化的构建(包含测试)来验证,从而尽快的检测出集成谬误。

    继续集成过程中的角色与职责如下:

    角色 职责
    开发人员 1. 实现开发工作,并在向版本控制库提交代码之前,先在本地环境实现一次公有构建。
    1. 批改反馈回来的代码问题,放弃集成构建的绿灯状态。|
      | 测试人员 | 依据我的项目停顿随时更新自动化测试脚本,并保障代码覆盖率达到团队要求。|
      | 运维人员 | 1. 依据开发人员的须要,及时更新保护自动化构建脚本。
    2. 保护整个 CI 流水线的失常运行。|
  • 继续交付(Continuous Delivery)

    继续交付(CD)是从构建环境到生产环境的构建、测试、配置和部署的过程。

    继续交付是一种软件工程手法,让软件产品的产出过程在一个短周期内实现,以保障软件能够稳固、继续的放弃在随时能够公布的情况。它的指标在于让软件的构建、测试与公布变得更快以及更频繁。这种形式能够缩小软件开发的老本与工夫,缩小危险。

  • 基础设施即代码(Infrastructure as Code)

    作为代码的基础设施(IaC)是描述性模型中的基础设施(网络、虚拟机、负载平衡器和连贯拓扑)的治理,应用与 DevOps 团队用于源代码雷同的版本。与同一源代码生成雷同二进制文件的准则一样,IaC 模型在每次利用时都会生成雷同的环境。

    IaC 是 DevOps 的要害实际,与继续交付联合应用。

    施行 IaC 的团队能够疾速、大规模的提供稳固的环境。团队通过代码示意环境的冀望状态,从而防止手动配置环境并强制实现一致性。应用 IaC 进行基础架构部署是可反复的,可避免因配置偏差或短少依赖性而导致的运行时问题。DevOps 团队能够与一组对立的实际和工具协同工作。疾速,牢靠,大规模的交付应用程序及其反对基础架构。

DevOps 转型的研发工具链

疾速交付的要害是“主动”与“牢靠”。主动是一个很宽泛的词汇,在软件交付中代表着测试自动化、交付自动化、运维自动化等,而牢靠讲的是每一次交付要保障是以后的交付是稳固的或可回滚到稳固版本的。

为了解决“主动”与“牢靠”的问题,麻利开发鼻祖 Martin Fowler 提出了继续集成与继续交付的概念,它所形容的软件开发,是从原始需要辨认到最终产品部署到生产环境这个过程中,需要以小批量模式在团队的各个角色间顺畅流动,可能以较短的周期实现需要的小粒度频繁交付。频繁的交付周期带来了更迅速的对软件的反馈,并且在这个过程中,需要剖析、产品的用户体验和交互设计、开发、测试、运维等角色密切协作,相比于传统的瀑布式软件团队,更少节约。通过这种小步快跑的形式,将小性能疾速迭代、验证、交付,通过自动化的工具,将测试、部署、运维自动化,缩小需要在软件生命周期中流动的工夫。

华为将本身积攒的先进研发能力与优良实际凋谢,交融麻利、精益、DevOps 等先进研发理念,打造凋谢残缺的云端开发生态,推出了一站式、全流程、平安可信的 DevOps 云平台——CodeArts,详情请参见 CodeArts 产品概述。

正文完
 0