devops和敏捷_DevOps的敏捷介绍–什么是DevOps？

devops和敏捷

本系列内容涉及DevOps及其如何适应敏捷世界。 我在苏格兰精益敏捷培训班（ 幻灯片 ）中给出了这个。

让我们从什么是DevOps开始。 我去了所有知识的源头，维基百科，定义如下：

“一种文化，运动或实践，强调软件开发人员和其他信息技术专业人员之间的协作与交流，同时使软件交付和基础架构变更的过程自动化。”

好吧，那不是很模糊。

另外，它并没有真正的帮助。 开发人员在那儿，可以肯定，但是Ops已转换为IT。 开发人员一直都需要IT并与之合作，那么在天堂的路上发生了什么？

到时间机器！

在2001年，有一个小事情叫做敏捷宣言 。 它谈到了工作软件 ，团队协作的结果。 如果将其应用于DevOps定义，我们将注意到以下几点：

“一种文化，运动或实践，强调软件开发人员和其他信息技术专业人员之间的协作与交流 ，同时使软件交付和基础架构变更的过程自动化 。”

显然，协作部分在那里。 它从敏捷宣言演变为原始的团队方面。 您会看到，在宣言发布之时（以及之前的十年，敏捷方法发展之时），“团队”的定义已经在扩大。

Scrum将“团队”定义为需要确保软件交付的任何人。 这意味着开发人员，测试人员和产品所有者（好的，这是一个单独的角色，但是如果没有采购订单，则没有任何有意义的交付）。 今天，我们需要团队中的更多技能。 自动化，部署，准备测试环境–这是确保软件正常运行所需的示例的简短列表。

DevOps实际上是“团队”定义的扩展。 我们可以将其视为新角色。 但是我们不应该。

我们非常喜欢角色扮演 ，我们将技能与角色混淆，并提出新的想法。 还有一些关于如何移交工作而不是如何完成工作的想法。

我们将DevOps视为一个角色或一个团队，将他们的工作与开发人员和测试人员的工作分开进行。 我们认为DevOps只是关于自动化的，因此尝试在这些职位上雇用，培训和升级人员。

这是错误的–经过大量的工作，创建了一支真正的多学科团队，我们再次建立了隔离墙。 事实是，我们所需要的技能，在团队，而不是外面 。

在我之后重复一遍：“独立的DevOps团队并不敏捷”。

DevOps不是角色。 这是一组...

99种技能，但DevOps不是一种

伙计，DevOps的技能非常丰富。 我们现在正在处理一系列全新的复杂问题，这些问题要么不存在，要么在九十年代才刚刚开始抬头。 难怪scrum没有定义它。

我们不再将软件放在34个磁盘上并寄出（感谢上帝）。 我们获得了需要针对业务运营进行优化的云服务，集群和业务流程。 为了部署和确保生产中的工作软件，需要积累的知识（其中一些知识还只有几年的时间）。

我们需要在内部设置环境，以便我们甚至可以在将其部署到外界之前进行开发和测试。 而且这些环境并不像它们周围那样复杂，因此我们需要模拟这些外部条件以进行正确测试。 当然，我们有更好的工具来管理这些东西。 但是我们仍然需要紧跟技术，工具，实施和升级它们。

而且，如果这还不是全部，那么生产中发生混乱的风险就增加了–我们再也无法在周末关闭服务器以不中断地部署我们的软件。 翻转开关之前，之中和之后，一切都需要保持运转。 另一方面，IT（或运营）在泥泞中告诉开发人员：“您无法触摸我们的生产服务器”的策略不再起作用。 我们需要更好的方法来保持业务发展。

工作软件很难。

让我困惑

我们需要技能和知识来平稳运行。 他们掌握了我们的问题和需求的答案。 但是现在我们有一些我们认为可以回答的问题：

• 什么是软件版本？
• 用版本控制术语定义功能的原因是什么？
• “准备发布”功能是什么？
• 什么定义环境？ 测试环境与过渡环境有何不同？随之带来的风险和缓解措施又如何？
• 什么是回滚？ 当人们每隔几秒钟将代码提交到生产环境时，我们会回退到哪个版本？

那只是短名单。

正如敏捷宣言所说，“我们正在发现开发软件的更好方法”。 我们仍然在定义真正的DevOps的过程中尚处于初期。 但是我们已经知道我们现在需要的技能和知识。

下次，我们将看到敏捷原理和DevOps实践如何与工作软件的目标保持一致。

翻译自: https://www.javacodegeeks.com/2016/10/agile-introduction-devops-devops-anyway.html

devops和敏捷