DevOps继承了敏捷软件的开发。DevOps的出现是应对敏捷方法带来的软件开发的增长率和生产率增长。在过去十年中敏捷文化和敏捷方法的开发中，这种总体方法更适合于交付到最终软件提供生命周期。
敏捷开发是许多迭代和增量软件开发方法的总和。最受欢迎的敏捷方法包括Scrum，看板，基于比例尺的敏捷框架（Safe?），精益开发和极端编程（XP）。
尽管每种敏捷方法都有其独特的方法，但所有敏捷方法都有共同的视觉和核心价值（请参阅敏捷声明），它吸收了由迭代和迭代带来的连续反馈。ESSENCEALL敏捷方法包括持续计划，连续测试，连续集成，连续集成，，以及其他形式的项目和软件本身的连续演变。敏捷方法具有轻巧的适应性。更重要的是，更重要的是，敏捷方法强调赋予团队能力，并通过合作做出快速有效的决策。
最初，敏捷团队主要由开发人员组成。这些敏捷团队在生产软件方面变得更加有效，因此将质量保证（QA）和开发分为不同的团队非常低，以提高软件的速度。交付，敏捷开发到包含的质量检查，现在敏捷的开发到所有阶段，包括交付和支持，敏捷的扩展到从概念到交付的所有阶段。
DevOps理想进一步简化了舞台的构建，验证，部署和交付阶段的软件变化，并扩大了敏捷开发实践，同时授权交叉努力团队拥有从设计到生产支持的软件应用程序所有权。
DevOps是一个IT想法，它鼓励软件开发人员和IT运营商之间的沟通，协作，集成和自动化，以提高交付软件的速度和质量。
DevOps团队专注于标准化的开发环境和自动化交付过程，以提高可预测性，效率，安全性，安全性和交付的维护。Devops的概念为开发人员提供了对生产环境的更多控制，并更好地了解生产基础设施。Devops鼓励团队鼓励该团队来赋予团队的能力，并让团队建立，验证，交付和支持其自主权的应用。在DevOps的情况下，没有什么能将其抛在墙上。
在开发DevOps应用程序之前，团队需要优先考虑收集业务需求，然后编写代码。完成代码开发后，除了开发外，其他QA团队将在独立的开发环境中测试该计划。如果已实施需求，则将当前版本交付给运营和维护人员进行部署。部署团队进一步细分为网络组和数据库等管组。当软件程序“抛在墙上”时，当“扔在墙上”时，将增加一层障碍。该模型的问题是团队单独工作时：
DevOps必须通过建立一个交叉乔布合作团队来应对这些挑战。这些团队负责维护操作软件系统并准备软件以在系统上运行，同时改善质量反馈和自动化问题。
开发团队的目的是发布尽可能多的新功能，因此他们向QA投掷了新版本。测试人员的目标是找到尽可能多的缺陷。当测试人员将其发现到开发时发现其发现时，开发人员将变得具有抵抗力，并将错误归咎于测试人员使用的测试环境。但是，问题恢复问题在测试环境中的问题不是他们的测试环境，而是开发人员的代码。
最终问题解决了。QA将“将其扔在墙上”的调试版本的新版本向操作和维护人员投掷。操作和维护团队的目标是限制系统的更改，因为他们担心发布代码发布代码将导致系统崩溃。他们的选择是一个单击的恢复系统。
操作和维护人员说，开发人员对他们提供的版本有问题，并且开发理论在测试环境中是正常的。然后操作和维护人员开始调试系统，直到达到生产稳定性为止。开发人员和开发人员和测试人员不管生产环境的运营如何，当操作和维护人员整夜解决生产问题时，他们将永远不会干预。
有必要改善所有相关STEM人之间的协作关系，从计划到交付以及交付过程中的自动化，以便：
根据2015年DEVOPS的报告，“高性能IT组织部署的频率增加了30次，交付周期缩短了200次；同时，它们的缺点减少了60次，恢复速度却下降了60次增加了168次。”
一个常见的预脱离场景：在新软件项目开始之前，软件团队（包括开发人员，测试人员，操作和技术支持者）组织会议。该团队计划如何构建现成的工作软件。
开发人员完成开发后，每天都部署新代码。自动测试可以确保可以部署代码的质量。在所有自动化测试后，代码将部署到少数用户。部署，新代码将受到监视，以确保其稳定并且没有不可预测的缺陷。监视表明它是稳定的，新代码将扩展到其他用户。计划和开发后最多可以完成计划和开发的步骤手动干预。
DevOps坐标可以帮助我们从不同角度审查DevOps。底部的水平轴指示哪些方面最关注的是DevOps。有些人坚信，Devops应该更多地关注文化而不是工具，而另一些人则倾向于注意工具而不是文化。
垂直轴描绘了DevOps交付链的三个级别：连续集成，连续交付和连续部署。DevOps社区在DevOps坐标的右上角称为粉红色独角兽，因为它极为罕见。这些独角兽由Netflix，Etsy，Amazon，Pinterest，Flicker，IMVU和Google代表，在最近的一项调查中，参与者对其组织的位置投票：
尽管意识形态领导者，敏捷教练和博客作者经常描绘右上角的DevOps愿景，但他们通常具有Devops文化或自动化工具的强烈倾向，并且关于谁对Devops文化或工具更为重要的辩论更为重要。但是现实是没有工具没有工具。没有强大的支持文化，所有工具将毫无用处。
另一个重要的一点是，向上移动需要时间。许多组织的第一步将是文化，工具和持续整合的整合，因此，如果您阅读了描述“不做DevOps”文章的内容，请不要灰心，不要否认，您就没有到达生产环境任何人类干预。
DevOps可能是您组织的有意义的文化，工具和成熟度的混合体，并且有意义的事情可能会随着时间的流逝而发展。重要的是，通过改善协作和自动化，软件交付阶段之间的障碍和瓶颈正在不断地努力工作在以下各章中，我们将探索DevOps坐标的各个方面，以帮助您更好地了解合适的位置。
Devops成熟的几个关键阶段。以下是您需要了解的一些关键阶段。
在持续集成之前，开发团队将编写三到四个月的代码。这些团队将合并其代码要发布。不同版本的代码将非常不同且更改，因此实际的集成步骤可能需要几个月。这个过程非常效率低下。
连续集成是一种惯例，可快速将新开发的代码与要发布的主要代码集成。当团队准备发布代码时，连续集成可以节省大量时间。
DevOps并未提出此术语。连续集成是一种敏捷的工程实践，该实践源自极端编程方法。这些术语已经存在一段时间了，但是DevOps采用了此术语，因为有必要成功实施连续的集成并需要自动化。连续集成IS是通常是迈向DevOps成熟的第一步。
从DEVOPS的角度来看，连续集成过程包括检查代码，该过程将其作为可用代码（通常是二进制可执行文件）编译并运行一些基本的验证测试。
连续交付位于连续集成的上方，这是[DevOps 2阶段2]的连续集成的扩展。在连续交付，需要额外的自动化和测试中，以便不仅实现代码，而且还经常将代码合并为中继代码也可以通过几乎没有手动干预来部署。这是一种使代码库处于现成状态的做法。
连续部署，不要混淆连续交付[Devops Nirvana]，是连续交付的最高演变。这种做法不需要任何人类干预才能直接实现生产环境部署。
连续交付团队将不会部署Unbet代码；新创建的代码需要在推入生产之前对自动测试的验证进行验证。编码发布通常首先面对少数用户，然后有一个自动反馈周期来监视质量和使用情况，并最终进一步扩散。
实际上，只有少数公司确实不断部署。典型的公司包括Netflix，Etsy，Amazon，Pinterest，Flicker，IMVU和Google。
大多数公司不会将Devops Nirvana作为最终目标，而是专注于不断提高继续交付的能力。
DevOps非常重视建立合作文化，并通过自动化的DevOps工具提高效率。尽管某些组织和人员认为其中一个比另一种组织更重要，但现实是具有成功的文化和工具来成功。对于DevOps的两个值，您需要知道以下内容。
DevOps文化的特征是增加协作，减少管仓库，分担责任，自主团队，提高质量，注意反馈并改善自动化。因为DevOps是一种敏捷的扩展，许多DevOps值是敏捷的值。
敏捷方法是一种更整体的软件交付方法。敏捷开发团队通过工作软件来衡量进度。同一目标。
DevOps在敏捷团队中增加了操作思维，或者有运营职责的团队成员。DevOps对客户进行了渐进式软件测量。
为了实现这一目标，开发人员和运营商必须打破管子仓库，彼此合作，分享软件操作系统的维护职责，并通过加强质量反馈和自动交付来准备软件以在系统上运行。
DevOps工具包括配置管理，测试和施工系统，应用程序部署，版本控制和监视工具。连续集成，连续交付和连续部署需要不同的工具。尽管这三个实践可以使用相同的工具，因为交付链的前进，更多工具，更多工具将被要求。
敏捷软件开发已经打破了需求分析，测试和开发之间的一些管子仓库，但是其他链接（例如部署，操作和维护）仍面临与软件开发的断开连接。DevOps运动旨在消除这些管子仓库，并鼓励开发和操作之间的合作和维护。
DevOps可能会因为结合了一些新的操作和维护工具并建立敏捷的工程实践而变得非常强大，但这还不足以实现DevOps的好处。如果您没有正确的文化，即使您使用了最好的工具，只是另一个时尚的术语。
DevOps文化的主要特征是加强开发与运营与维护之间的协作。为了支持这一合作，团队和组织层面有一些重要的文化变化。
责任共享是DevOps文化中更紧密合作的具体表现。
对于开发团队，如果将系统的操作和维护（他们开发）转移到另一个团队，那么他们将很容易注意他们。然后，他们可以感觉到操作和维护人员的疼痛点，并找出简化释放和维护的方法（例如自动部署和加强日志）。
他们还可以从系统中获得监视产品的观察需求。当运营和维护人员共享系统的业务目标时，他们还可以与开发人员进行更紧密的合作，以便更好地了解系统的运营需求并帮助团队满足团队满足它。
实际上，协作通常始于运营和维护的意识（例如部署和监视）以及开发人员的操作和维护人员采用新的自动化工具和实践。
为了支持责任共享的文化，需要一些组织级别的变化。开发与运营和维护之间不应有管道仓库。
对于从一开始就从事解决方案的工作方法，转移周期和文档不是一个好的实践形式。
有助于团队可以调整资源结构的原因，以便更早地将运营和维护人员整合到团队中，以便开发人员，运营和维护人员坐在一起可以帮助他们一起工作。转移和签名将阻碍人们分担责任并带来责任并带来责任投诉文化。
相反，开发人员以及操作和维护人员应对系统的成功或失败负责。删除文化模糊了开发与操作和维护角色之间的边界，并最终消除了该角色之间的差异。
当为组织介绍DevOps时，一个共同的计数器模式是为某人分配“ DevOps”角色或团队为“ DevOps团队”。使用管仓库的使用是巩固的，最初，该管仓库最初被破坏了。
组织的另一个有价值的变化是自组织的团队。
为了使发展与运营和维护人员之间的合作更加有效，他们需要做出决策并实施变更而不依赖复杂的决策 - 制定过程。这需要信任团队，改变风险管理的方式并创建安全不需要害怕失败的环境。例如，团队必须生成更改列表以签署更改列表以部署测试环境，然后团队可能会经常延迟。可以依靠版本控制，因为版本控制也是可靠的和审核的。版本控件的更改可以连接到团队项目管理工具中的表单。没有手动签名，团队可以自动部署并加速其测试周期。
DevOps文化的转变带来的效果是，新功能比以前更容易在线到生产环境。这对于未来的一些更深层的文化变化非常必要。“为了确保产品的变化可靠，团队需要注意“开发过程中的建立质量”的价值。这包括跨功能的注意事项，例如性能，性能和性能和性能，类似的安全。交付，包括自我检验，构成了允许我们进行周期性和低风险部署的基础。
为了不断改善开发人员，运营和维护人员的合作方法，并为团队改善系统本身，他们还需要注意反馈。用于诊断问题和持续改进，生产环境监控是非常有帮助的反馈电路。
自动化是DevOps运动的基石，促进了协作。例如，例如测试，配置和部署释放等自动化方法可以使人们解放以专注于其他更有价值的活动并减少人造错误。自动化带来的“有用的副作用”是：自动化脚本和测试可以用作有用的，并且总是更新的文档，这些文档很有用，并且始终在及时更新。例如，自动服务器配置可以消除与雪花服务器相关的猜测工作这意味着开发，操作和维护人员也可以了解如何配置服务器的更换。
上一篇文章简要讨论了DevOps使用的一些工具，下面列出了一些需要知道的关键工具和实践。
开发人员使用源代码库签名和修改代码。源代码库管理代码的每个版本，因此开发人员不会覆盖彼此的工作结果。
源代码控制已有40年的历史，它仍然是连续集成的主要组成部分。受欢迎的源代码管理工具包括GIT，Subversion，CloudForce，BitBucket和TFS。
构建服务器是将源代码库中的代码编译为具有可执行代码的自动化工具。受欢迎的工具是Jenkins，Sonarqube和Artifactory。
配置管理定义了服务器或环境的配置。流行的配置管理工具包括木偶和厨师。
亚马逊的Web服务和Microsoft Azure是典型的虚拟基础架构。虚拟基础架构由销售基础架构或平台的云制造商提供，即服务（PAAS）。这些基础架构为使用配置管理工具（例如Pupp and Chef）提供了针对新机器的API。
此外，还有一个私有云，例如VMware的VCloud.Private Virtual Infrastructure，可以在其自己的数据中心的硬件上运行。
与自动化工具一起，虚拟基础架构正在增强组织DevOps的能力，并且配置服务器不再需要任何键盘操作。如果您想测试新开发的代码，您可以自动将代码发送到云基础架构，构建环境，并在没有人类干预的情况下进行所有测试。
自动化测试的历史悠久。DEVOPS测试重点是在装配线中构建自动测试，以确保对部署的施工有足够的信心。要连续部署，我们必须相信，该代码在没有任何手动干预的情况下部署。没有全面的自动化测试，就无法实现连续部署。受欢迎的工具包括硒和沃特。
像制造和装配线一样，装配线是从开发人员提交给生产环境或生产环境的代码或后来的出生环境中的。
versionOne vs集成了生命周期管理和DevOps的敏捷应用，该应用程序提供了平台上整个软件交付的全部图片。DevOps的整个软件交付。和整个软件交付周期变更过程的可视化。
帕特里克·德博斯（Patrick Debois）是一名软件开发顾问，他的目标之一是研究其所有方面。为此，帕特里克（Patrick）在15中担任了许多不同的IT职位，例如开发人员，网络专家，系统管理员，测试人员和项目经理。多年来体验IT组织中的每个角色并获得对IT的总体理解。
帕特里克（Patrick）在一个大型数据中心迁移项目中进行了咨询。在这个项目中，他负责测试，因此他必须与开发人员和运营商合作很长时间。。在这个数据中心的迁移中，面对管理层跳跃发展团队和运营团队的挑战，他特别沮丧。
持续的集成在敏捷社区中越来越受欢迎，并且更接近开发人员的部署，但是仍然没有什么可以完全跨越开发团队和运营团队的差距。Patrick认为，将有更好的方法来共同努力来共同努力一起工作。
安德鲁·谢弗（Andrew Shafer）在2008年敏捷会议上提交了一个临时主题，即“敏捷基础设施”。帕特里克·德博斯（Patrick Debois）在他看到这个话题时参加了会议，但只有他参加了自己，但很少有人对这个临时话题感兴趣，安德鲁本人和安德鲁本人尚未出现。
幸运的是，看到其他人也有兴趣解决开发团队与行动团队之间的合作挑战，帕特里克热情地发现了安德鲁·安德鲁。两人决定建立一个名为敏捷系统管理的Google讨论团队。
在圣约瑟夫举行的奥莱利速度会议上，约翰·艾尔施（John Allspaw）和Flickr工程总监Paul Hammond，Flickr Technology Operation的高级副总裁Paul Hammond发表了著名的演讲，“ 10部已部署-Flickr开发团队和运营团队合作。”演讲奠定了如何有效合作开发团队和运营团队以改善软件部署的基础。
帕特里克·德博斯（Patrick Debois）通过现场视频观看了比利时的演讲，并受到了启发。他在比利时的Genet，Devopsdays发起了自己的会议。这次会议聚集了一群具有攻击性，前瞻性和努力改善软件部署的精英。更重要的是，这群人继续与#DevopsDays Tag讨论在Twitter上。为了保存针对Twitter讨论的角色，每个人都删除了标签中的日子，标签变成#Devops。
第二年，Devopsdays在澳大利亚和美国举行。随着时间的流逝，越来越多的Devopsdays在世界各地的不同国家和城市举行。面对面的面积会议激发了越来越多的人对Devops的热情启发直到它成为全面的基层运动。
直到2011年，DevOps运动一直由个人和开源工具驱动，很少有分析师或供应商关注。但是2011年，运动开始成为主流，吸引了Cameron Haight和451 Research的Jay Lyman.large供应商等分析师。持有Devops。
到2012年，DevOps很快成为一个流行的词，Devopsdays继续增长。
公众对DevOps信息的渴望赋予了几位受此主题的作者。介绍最多的书是Gene Kim，Kevin Behr和George Spafford，Mary Poppending和Tom Poppending的“ Phoenix Project”。
像Target，Nordstrom和Lego这样的大型公司成为第一批推出DevOps的公司。
社区翻译：Cui Longbo guo ying Liu Haiyan Shangjun领导学校：Zhang Biao Yuan作者：合作版本和Martin Fowler原始地址：https：// resources.collab.collab.net/devops-101/ What What Whats Whats Whats Whats Whate-Devops