红帽已经加入了不断壮大的优秀科技播客行列，推出了新项目 Command Line Heroes。
在前两集中，开发者兼主持人 Saron Yitbarek 讲述了开源软件和 Linux 在 80 年代和 90 年代如何获得发展的。然后，在季终集之前的接下来四个剧集中，她对敏捷、DevOps、容器和云进行了简短而有力的历史介绍。
让我们来看看敏捷和 DevOps 的剧集。 下一次，我将向您介绍关于容器和云的剧集。
催化剂
随着互联网的出现，公司需要以极快的速度交付服务和应用程序。 "一切都与更快的上市时间、更高的敏捷性、更多迭代、而不是更长时间的大型工作有关，" Ansible 产品经理 Richard Henshall 说道。
开发人员是骑着马来拯救世界的英雄和女英雄，开发人员的角色提升到了前所未有的地位和声望。与任何这种规模的变化一样，开发人员的工作流程经过了分析、尝试、测试和重新构想。 这引入了开发人员未来工作方式的两大变革：敏捷和 DevOps。
首先，敏捷
敏捷方法诞生于 2001 年冬天在犹他州举行的软件开发会议上。 在那里，起草了 宣言，其 原则 列表以
“我们最重要的目标，是通过尽早和持续地交付有价值的软件来使客户满意。 欢迎对需求进行变更，即使在开发后期也是如此。 敏捷过程利用变更来为客户创造竞争优势。”
敏捷方法在今天的开发者中继续得到采用，热门电视剧 硅谷 制作了这个关于敏捷的片段（以及 scrum）
要了解更多关于敏捷兴起的信息，请收听第 3 集。
然后，DevOps
这是设置。
在 Stripe 的可靠性工程团队工作的 Jonah Horowitz 这样描述这个问题：
“运维团队通常以正常运行时间和可靠性来衡量，而提高正常运行时间的最大方法之一是减少系统中的更改量。 但当然，发布新功能正在改变系统，而从事产品工作的软件工程师有动力尽快发布尽可能多的功能。 所以，当您有这些不同的角色时，您会在开发和运维之间设置这种冲突。”
微软 .NET 和 ASP.NET 的首席项目经理 Scott Hanselman 这样描述解决方案：
“2008 年维基百科关于 DevOps 的定义实际上非常好。 因此，它是一组旨在减少提交更改和更改投入生产之间的时间，同时确保质量的实践。 所以如果你想，嘿，我检查了一些代码。 现在是星期二，将在六月份的发布中发布。 这太糟糕了。 那将不是持续集成。 那将是一年几次的集成。
如果您有一个良好的健康 DevOps 系统，如果您已经完成了设置实践，那么您将不断集成到生产中。 那么，你能做什么？ 你可以定义、可以创建哪些最佳实践，允许你得到它？ 所以，我周二检查了一些代码，周四投入生产。 现在这是重要的一点——暂停以产生效果——同时确保高质量。”
红帽高级经理 Gordon Haff 谈到做好 DevOps 需要什么
“您确实需要一个全新的工具生态系统才能最有效地进行 DevOps。 我们看到的是 DevOps 可以利用的大量新型工具和平台。 它们实际上都来自开源。”
要了解更多关于开发人员和 IT 领导者如何通过 DevOps 实践解决速度和思维模式的问题，以及自动化所起的作用，请收听第 4 集。
延伸阅读
我将以一些很棒的链接和我觉得重要的延伸阅读来总结一下。
了解记者和敏捷的伟大思想家在这一主题上写了什么。
关于敏捷历史的文章
撰写宣言的人的反思
- 原始网站上的关于作者的信息
- 原始网站上的简短历史
- Martin Fowler 撰写的编写敏捷宣言
- Alistair Cockburn 撰写的我如何拯救敏捷和世界其他地方
- Robert Martin（又名 Uncle Bob）撰写的敏捷联盟的成立
- Dave Thomas 撰写的敏捷已死
了解 DevOps 的伟大思想家在说什么。
- 这份 麦肯锡报告 发现，计划到 2020 年实施 DevOps 的公司大幅增加。
- 红帽布道者 Gordon Haff 谈论 DevSecOps 和 DevOps 指标的 3 个警告标志。
- Opensource.com 上的 DevOps 文章集合探讨了反馈循环、团队动态、系统管理和运营的交叉点以及最佳实践。
- 关于云计算时代如何重新定义运营系统管理员角色的书籍：什么是 DevOps？，作者：Mike Loukides
订阅播客
通过您最喜欢的播客接收器订阅（请参见下面的一些），并访问 redhat.com/commandlineheroes 以访问演示、特殊操作方法并注册时事通讯。
评论已关闭。