개발 운영을 이해하고 개발 운영 팀의 응용 프로그램이 소프트웨어 전달 및 제어를 개선하기 위해 큰 의미입니다 마스터, 현재 IT 분야에서 가장 뜨거운 주제 중 하나입니다. 그러나 현재까지 개발 운영의 통일 된 정의는 없다.
개발 운영 배경, 진화 및 방문 값의 정의의 출생의 비즈니스 및 IT 측면의 개발에서이 문서를 분석하고 개발 운영 팀의 의미를 탐구하기 위해 설명되어 있습니다.
2009 년 제시하기 때문에 개발 운영, 그것은 10 년 동안왔다. 최근 몇 년 동안, 개발 운영 열이 빠르게 상승했다 추세는 세계 최고의 개발 운영 산업의 응용 프로그램의 범위가 모멘텀까지 30 %에 도달 한 2018 년 말까지 DORA의 연례 보고서에서 볼 수 있습니다.
그러나 지금까지 개발 운영팀 여전히 개발 운영 팀에 대한 우리의 이해를 위해 또는 방문 개발 운영팀의 과정에서 적지 않은 곤란을 겪을 것 정확한 정의를하지 않아도, 당사자들은 자신의 이해를 가지고있다. 그래서, 그것은 무엇의 의미를 개발 운영 팀? 우리는 진화 및 방문 값의 정의로 개발 운영 배경의 개발을 탐구하는 시간부터 기대합니다.
개발 배경을 개발 운영
사업 개발은 소프트웨어에 따라 달라집니다
소프트웨어 시스템의 중요한 부분으로, 점차 개발, 서비스 및 소프트웨어를 통해 뷰의 전체 관점에서, 사회의 구석 구석에 침투하는, 2000 년 호황 이후 1980 년대 시민 응용 소프트웨어 시스템의 상승, 관계형 시스템은 3 단계로 나눌 수 있습니다.
가벼운 의존
주로 초기에이 단계에서 소프트웨어 시스템은 주로 비즈니스 프로세스의 일부 지원의 범위에 국한 반복 비즈니스 또는 계산 부하, 이상을 해결합니다. 비즈니스 소프트웨어 시스템은 소프트웨어 사업이 필수는 수행 할 수 있습니다 또는,이 단계에서, 업데이트 소프트웨어 기능의 주파수가 일 또는 몇 달, 년이 될 수있었습니다.
의존도
비즈니스 개선 사업의 개발, 관련성과 복잡성, 완성 된 인공에 전적으로 의존하는 사업은 불가능하게되었다. 이 기간에, 핵심 시스템 소프트웨어 지원 사업, 비즈니스 소프트웨어 불가분의 관계에있다가 있지만, 비 존재의 서비스의 허용 짧은 기간, 업데이트 빈도 소프트웨어 기능은 몇 일, 월 필요합니다.
완전히 의존
随着软件服务深入社会各个角落，社会生活的衣、食、住、行、用都依赖于软件系统，从某一领域或应用来说，软件系统相对于业务已经进入了主导阶段，软件系统必须提供365*7*24的服务，任何中断服务可能都会带来极大的经济或社会损失，软件功能的更新频率必须控制在数天、小时、分钟。
IT管理与研发模式演进
IT管理与研发模式的演进，与IT对业务的响应效率密不可分，大致可分为三个阶段；
“稳态”模式
传统稳态模式的管理上，业务、研发、测试、运维依次分阶段管理，各阶段的人员只需关注本阶段内部的相关内容即可，研发以系统软件包交付为目标；整体结构如下图所示：
在研发模式上，以瀑布模型为主要特点，其优势是各阶段划分比较清晰、整体成本较低，但迭代速度较慢，其在业务对软件轻度依赖阶段适用性较好。
“稳态+敏捷”模式
随着业务对软件依赖程度的提高，传统模式下软件的迭代效率成为了一个阻碍业务发展的主要问题点，于是针对软件研发过程最耗时的开发过程出现了一系列的优化措施，敏捷研发是其代表。这个时期的IT管理模式变成了“稳态+敏捷”的模式，研发仍旧以系统软件包交付为目标，如下图所示：
当然，在这个时期，针对各阶段的效率提升也进行得如火如荼，出现了了一大批针对不同阶段提速的工具软件，如下图所示：
“敏态”模式
当业务对软件系统完全依赖时，IT管理与研发模式就需要进入“敏态”模式了。而这个模式也就是我们今天时常提起的DevOps。在这个模式下，研发交付目标不再是系统软件包，而是面向业务的服务能力，如下图所示：
由于业务与软件的关系越来越紧密，研发的交付已经由原来的面向软件包产品，而转向面向业务需要的服务能力，然而，这种服务能力也是涉及多个方面，下面我们从DevOps的定义发展，来看看DevOps的内容丰富过程。
DevOps定义演进
“稳态+敏捷”模型只能实现局部效率提升，而DevOps那么唯一的途径就是从整体上进行优化和提升，使整个研运过程形成一个有机的整体。从2009年提出依赖，DevOps的内涵也在进行着不断的发展与丰富，我们先看一下不同时期的定义。
2009年10月，【Patrick Debois】DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
2010年5月，DevOps是一个重要的理论，它通过敏捷、精益等在方法、在一个传统的组织中，把独立的部门协同在一起实现跨部门集成，建立更加紧密的多部门协作。DevOps不仅仅关注软件部署这一技术问题，它是考虑部门与部门之间沟通和协作的管理方法。
2014年12月 DevOps是一种软件开发方法，它强调软件开发人员和信息技术人员之间的沟通、协作和集成。
2015年11月 DevOps是一种文化、运动或实践，它强调软件开发人员和其他信息技术人员的协作和沟通，同时强调自动化软件交付和基础设施变更的过程。
2018年AWS DevOps定义:DevOps是一组实践，目的是在确保高质量的情况下，快速地把变更导入到生产环境。
我们把不同时期的定义整理为一个时间轴，并做一些关键字抽取：
可以看出针对DevOps的定义，随着时间的推移，DevOps的内涵在不断丰富，已经从最初一组过程、方法与系统的组合简的单定义，发展为一套有理论、有方法、有文化、有实践的体系。
DevOps体系与传统模式是有着本质的不同的，主要体现在以下几个方面：
组织方式不同
DevOps中强调以项目或产品的一体化管理为基本管理模式，从而消除传统模式下分阶段任务管理与执行，通过管理模式的调整，消除传统模式下不同阶段的衔接问题。
关注重点不同
DevOps是以最终向业务的服务能力交付为目标，而不是传统模式下分阶段任务交付为目标。
提升维度不同
DevOps关注软件系统的整个生命周期，是从整体上提升软件交付的质量与效率，而不单只关注某一个阶段的提升，各阶段的提升可以更加的有机协同。
管控深度不同
DevOps强调全程监控，全程度量，通过技术手段透明化软件交付的全程，包括过程与结果，而传统模式下过程数据缺乏，难以进行有效的过程度量与分析。
效益效果不同
DevOps支持针对交付过程的持续优化，通过度量数据分析可以快速定位交付过程的问题与努力方向，支持持续科学的优化提升，传统模式难以做到。
DevOps落地价值
DevOps的定义演进以及与传统模式的对比，可以看出DevOps体系本身系统化、整体性的设计思想，其既包括了软件全生命周期的系统化考虑，也包括了了IT管理的多方诉求，DevOps的落地涉及DevOps平台的建设、流程体系建设、人员赋能、标准规范等多个方面，其可以为带来如下方面的提升。
业务响应能力提升
DevOps的落地，在提升效率的同时可以提升交付的质量，自动化程度的提升可以提升对业务需求迭代的响应能力，研运吞吐量可以得到几何级的提升。
研发交付规范提升
不同项目或产品的研发团队，在同一套平台上开展研发交付活动，通过平台预先制定的流程、规则等约束不同研发团队的交付活动，从而实现研发交付规范与标准的统一，实现企业级的优化提升与改进。
研发交付效率提升
通过针对研发交付过程中的环境准备、编译构建、代码质量检查、系统测试、软件部署等过程的自动化实现，降低人工操作或等待人工操作时间，全面提升研发交付过程的自动化水平，提升研发交付效率。
研发交付质量提升
研发交付质量的从现有的部署结果质量保障，延伸到源代码质量保障、测试覆盖度保障等过程，从而实现从源代码到部署全过程的质量检查与提升，全链路提升研发交付质量
研发交付管控提升
针对研发交付的需求、开发、测试、发布和部署等过程，进行全面的数据化和度量，针对重点关注指标建立质量门禁，从而实现自动化的技术管控，结合已有的行政管控，由单一的结果管控，实现研发交付“过程+结果”管控，提升管控力度。
研发交付持续优化
基于DevOps平台，通过流水线过程数据收集，以及进一步的度量分析，实现研发交付过程的持续优化，既包括DevOps平台的优化，也包括研发交付流程、标准规范等方面的优化。
개요
그것은 구축 할 수있는 기술의 개발 운영 및 실천 문화의 간단한 진화;에 의존 무관에서, 지역 비즈니스에서 모두. 개발 운영 구현 연구, 운영 통합 및 비즈니스 요구에 대한 응답을 향상의 가치가. 추세가되어 있습니다, 우리는 기꺼이 축제를 가입 할 수 있습니다.
저자 : 전체에서 황