尽管敏捷开发方法已兴起，但多年来，开发团队和运营团队仍然处于孤立状态。DevOps 是协作工具和实践的进一步发展，以更快速地发布更优质的软件。
打破开发与 IT 团队之间的屏障
DevOps 运动在 2007 到 2008 年间开始盛行，在当时，IT 运营和软件开发社区直言不讳地表述了他们所认为业界的致命性障碍。
它们与传统的软件开发模式相左，后者要求代码编写人员在组织和功能上与代码部署和支持人员分开。
开发人员和 IT/运营专业人士的对象、部门领导、评估的关键绩效指标千差万别，且通常具有竞争性，其所在的楼层甚至所在的办公大楼也都不尽相同。这样所造成的结果是：团队内部相互孤立，只关心各自领域内的事物；工作时间较长；发布混乱；以及客户的不愉快体验。“当然有更好的方法”，他们表示。因此，两个社区聚在一起，并派出能够推动对话的人员（比如 Patrick Dubois、Gene Kim 和 John Willis）进行了交谈。
在网络论坛和本地创客聚会上兴起的事物现已成为软件时代精神中的重大主题，这可能也是您来到此处的原因！您和您的团队正承受着企业内孤立团队和受损沟通线所带来的痛苦。
您虽然在使用敏捷开发方法进行规划和开发，但在发布代码时仍会竭力避开一系列戏剧性事件。您可能已经听说过 DevOps 及其对团队的看似神奇的影响：Atlassian 对 500 名 DevOps 从业人员的一项调查表明，几乎所有 (99%) 的 DevOps 团队都坚信其投入生产的代码会取得成功¹。
然而，DevOps 不是魔法，无法在一夜之间完成变革。好消息是，您不必等待上级管理层推出大型计划。通过了解 DevOps 的价值并持续做出细微的改变，您的团队即可马上开启 DevOps 之旅。
超越敏捷开发
DevOps 涉及开发和运营生命周期的每个阶段。从规划和构建到监控和迭代，DevOps 汇集了工程和 IT 组织各个方面的技能、流程和工具。
敏捷开发方法将工作分解为可管理的任务和里程碑，从而帮助团队进行规划和生产。敏捷开发依靠冲刺、待办事项、长篇故事和故事将工作分配给技能熟练的团队成员，在必要时调整时间线，并向客户提供优质的产品和服务。阅读有关敏捷开发的更多信息。
持续集成和交付：持续集成和交付是 DevOps 实践的基石，它依赖于代码的自动合并和部署。传统的开发方法要求工程师手动更新代码库中的变更，并进行额外的手动检查，以确保高质量的代码已准备好投入生产。部署计划延迟数周或数月，以消除出现缺陷或事件的可能性。DevOps 实践通过自动执行合并、测试和部署功能来消除这些延迟。高绩效团队使用 CI/CD 将部署频率从数月一次增加到一天数次。阅读有关 CI/CD 的更多信息。
Git 存储库和工作流支持自动化和版本控制功能，这些都是 DevOps 实践的基础。由于 Git 是分布式的，因此会加快诸如提交、归咎、差异、合并和记录等操作的速度。Git 还为创建存储库历史记录分支以及合并和重写存储库历史记录提供卓越的支持，这有助于实现很多功能强大的工作流和工具。了解有关 Git 的更多信息。
IT 服务管理是 IT 团队用来管理面向客户的端到端 IT 服务交付的流程。其中包括设计、创建、交付和支持 IT 服务的所有流程和活动。ITSM 的核心理念就是相信 IT 应该作为服务交付，这超出了基本的 IT 支持范围。ITSM 团队监督各种工作场所技术，从笔记本电脑到服务器，再到业务关键型软件应用。阅读有关 ITSM 的更多信息。
事件管理团队负责对计划外事件或服务中断做出响应，并将服务恢复到运行状态。在“谁构建，谁运行”模型中，开发人员与运营团队合作，以降低事件发生的可能性，同时在事件发生时缩短平均恢复时间。阅读有关事件管理的更多信息。
DevOps 的状态
组织和团队继续采用 DevOps 实践和工具。Atlassian 在对 500 名 DevOps 从业人员的调查中发现，50% 的组织表示他们已经使用 DevOps 超过 3 年。
遗憾的是，尽管就 DevOps 的定义和实施 DevOps 实践的好处达成了一致，组织和团队仍在努力实现 DevOps 的承诺。团队必须专注于持续反馈、迭代和改进，以便更好、更快地进行部署，满足客户的需求。
您可以通过我们的《DevOps 初学者指南》了解 DevOps 最佳实践。要将 DevOps 付诸实践，我们建议尝试 Open DevOps，它提供了团队开发和运营软件所需的一切。借助与领先供应商和 Marketplace 应用的集成，团队可以构建他们想要的 DevOps 工具链。立即试用。