DevOps 历史

开发和运营团队如何共同解决行业中的功能障碍。

尽管敏捷方法学不断涌现,但开发和运营团队多年来仍然处于孤立状态。DevOps是协作工具和实践的下一步发展,可以更快地发布更好的软件。

将开发团队和IT团队联系在一起

DevOps运动在2007年至2008年之间开始合并,当时IT运营和软件开发社区对他们认为该行业功能失调的致命程度感到担忧。

他们反对传统的软件开发模型,该模型要求编写代码的人员在组织和功能上与部署和支持该代码的人员不同。

开发人员和 IT / Ops专业人员 有单独的(并且经常是相互竞争的)目标,单独的部门领导,单独的关键绩效指标(根据这些指标对其进行判断),并且经常在不同的楼层甚至不同的建筑物上工作。结果是孤立的团队只关心自己的领地,长时间的工作,发布不当以及客户不满意。他们说,肯定有更好的方法。因此,这两个社区聚集在一起并开始交谈。

您正在使用 敏捷方法进行规划和开发,但是仍然很难在没有很多麻烦的情况下将代码发布出去。您可能已经听说了有关DevOps的一些事情,以及它可能对团队产生的神奇影响:在对500位DevOps从业人员的调查中,几乎所有(99%)的DevOps团队都对他们的代码成功投入生产充满信心。由Atlassian¹进行。 

但是,DevOps并不是魔术,而且转换不会在一夜之间发生。好消息是您不必等待高层管理人员推出大规模计划。通过了解DevOps的价值并进行细微的增量更改,您的团队可以立即踏上DevOps之旅。


超越敏捷

DevOps涉及开发和运营生命周期的每个阶段。从计划,构建到监视和迭代,DevOps汇集了工程和IT组织各个方面的技能,流程和工具。

敏捷方法论可将工作分解为可管理的任务和里程碑,从而帮助团队进行计划和生产。敏捷依靠冲刺,积压,史诗和故事将工作分配给熟练的团队成员,在必要时调整时间表,并为客户提供优质的产品和服务。

持续集成和交付:持续集成和交付是DevOps实践的基石,DevOps实践依靠自动化代码的合并和部署。传统的开发方法要求工程师手动更新代码库中的更改,并进行额外的手动检查,以确保准备好将质量代码交付生产。部署计划有数周或数月的延迟,以消除出现错误或事件的可能性。DevOps实践通过自动化合并,测试和部署功能消除了这些延迟。高绩效团队使用CI / CD将部署频率从每几个月一次减少到每天多次。

Git存储库和工作流启用了自动化和版本控制功能,这些功能是DevOps实践的基础。由于Git是分布式的,因此诸如commit,blame,diff,merge和log的操作会更快地发生。Git还支持分支,合并和重写存储库历史记录,从而支持强大的工作流程和工具。

IT服务管理是IT团队用来管理向客户端对端交付IT服务的过程。这包括设计,创建,交付和支持IT服务的所有流程和活动。ITSM的核心概念是认为应将IT作为服务交付,这超出了基本的IT支持。ITSM团队负责监督各种工作场所技术,从笔记本电脑到服务器,再到关键业务软件应用程序。

事件管理团队对计划外事件或服务中断做出响应,并将服务恢复到其运行状态。在“构建,运行”模型中,开发人员与运营合作,以减少事件发生的可能性,并减少事件发生时的平均恢复时间。

觉得文章有用?

点个广告表达一下你的爱意吧 !😁