需要DevOps !

要深入了解人们对事物的感知和理解，只需看看社交网络。

来自一家正在寻找DevOps领导者的公司的这条消息让我问了自己一个大问题，关于市场对DevOps的看法和理解。

但是DevOps真的是一个在组织中扮演这个角色的人吗?但首先，什么是DevOps?

根据维基百科，定义如下:

“一种文化和专业运动，强调软件开发人员和IT运营专业人员之间的沟通、协作和集成，同时自动化软件交付和基础设施变更的过程”

本质上，这是我的理解和解释DevOps,

这是一种旨在带来相互共鸣对两组来说Dev而且运维他们的目标相互抵触。因此，DevOps实践的应用将允许实现每个组的特定目标，同时尊重其他组的责任。

我提到两个团队时，理想情况下，应该只有一个，但不幸的是，历史上，甚至今天，这是两个不同的团队，没有相同的目标。一个是尽可能快地交付业务价值，另一个是尽可能拥有最稳定的基础设施。

现在，要让它起作用需要做两件事，首先需要一个框架来构建业务价值交付过程，例如Scrum或看板。所选择的敏捷方法，将允许整个组织和开发团队产生价值——甚至是每天的每一次迭代。

其次，有必要拥有一套自动化工具，允许运维和开发人员在尊重每个组的目标和职责的同时，跟踪组织业务价值的交付率。

来最大化执行的机会在组织内的DevOps实践中，必须将两个基本标准有一个框架来构建业务价值交付过程和一套工具。如果只有IT部门愿意通过工具实现DevOps，那么整个组织将无法遵循并将其视为没有实际价值的支出。如果意志来自组织和敏捷交付训练，而IT团队没有必要的知识和工具，实践的实施将给组织带来很大的压力，它将不会取得预期的成功。

因此，第一步是建立一个框架来构建和指导价值工作流，例如Scrum或看板。通过Scrum或看板的良好应用，组织将能够支持客户需求从实现到交付的频繁甚至日常交付。

另一方面，为了能够实现DevOps实践，业务价值交付过程在整个组织中达到一定的成熟度是必要的。

我的意思是，通常当一个组织决定采用Scrum或看板来实现敏捷化时，框架的应用只会停留在开发团队中。随着团队在敏捷方面的日益成熟，团队通过包括业务和IT运营来扩展敏捷的范围。

这时组织可以更容易地在其开发和运维团队中实现DevOps实践。另一方面，只有当他们拥有正确的工具时，这才有可能，这就引出了第二个标准。

这就是为什么团队拥有一个包含实现这些目标的所有工具的工具箱是至关重要的。通常，需要为以下每个类别找到一个或多个工具:

• 版本控制和工件存储库
• 持续集成/持续交付
• 质量检查
• 自动化测试工具
  • 包括静态代码分析检查器
  • 自动化测试框架
• 性能测试工具
• 自动化发布/部署工具
• 基础设施即代码:软件定义的配置管理。
• 虚拟化和容器化技术

如果我回到最开始的Linkedin帖子，一个公司正在寻找一个DevOps负责人，正如我们所看到的，不可能只有一个人，甚至是一个团队，来负责DevOps实践。因此，如果你想在你的组织中建立一个实用的DevOps，确保你有两个基本的标准，特别是授权给整个组织，而不是一个团队或个人。